

内存基础知识（十九）-- 奇怪的流量分布：在BankGroup层观测流量

IT知识刺客

2025-11-21

导读：这是内存基础知识系列的第19篇，你可以在基础软件开发，找到前18篇。

这是内存基础知识系列的第19篇，你可以在基础软件开发，找到前18篇。

上一篇内存基础知识（十八）-- 虚拟地址/物理地址/内存地址, 有何不同中，提到可以通过观测流量，破译“神秘的”编址规则。这一篇我们就实际动手试试。

再额外唠叨几句，我发现很多人不喜欢做实验。在探索底层原理的时候，没有什么比做实验更直接的方式了。

有了实验数据，可以避免很多无谓的争论。

最重要的，实验过程还能把自身所学全都串起来。用“大厂味”话说，这叫形成“闭环”。

下面，我首先以测试程序为抓手，通过逐步拆解测试程序，再进行实验、收集数据，最后分析数据、与内存原理印证，最终咱们一起“闭环”。

闭环之后，更进一步，和算法相结合，把底层硬件的潜力充分发挥，提供更强的算力，这叫“赋能"。

好了，赋能的事先放一放，先从抓手开始：解析内存流量测试程序。

首先，既然是测试内存流量，当然要尽量避免L1~L3 Cache的影响了。这很容易做到：

    for(j = 0; j < loop_number_1; j++)    {        for(i = 0, arr1 = arr; i < loop_number_2; i++)        {            k += *arr1;            arr1 = (TYPE *)(((char *)arr1) + step_size);  // 地址向后加至少 64字节        }    }

内存流量测试程序片段1

第 6 行的地址后移操作，至少移64字节就可以避免Cache的影响。

因为Cache Line Size通常都是64字节。

Cache Line Size是 Cache 层概念。内存系列完结后，我计划就开讲Cache系列，这里先提一下，Cache也不是一个字节一个字节读写的，也要按“块”读写。Cache的块叫Line，Line的大小通常都是64字节。

注：我接触过的，只有飞腾 CPU 的Cache Line Size是128字节。

你读任意一字节内存，CPU会把它所在的64字节，读入各级Cache。如果下一地址和前一地址不超过64字节，就有可能Cache Hit。

因此，第6行中的step_size，应该是64字节的倍数。

（注：不是从你读的内存地址开始的64字节，而是它所属的某一个Line。）

“测试程序片段1“中第3到7行的内循环，如图1所示：

图1 step_size 为 64

就是以step_size为步幅，跳着遍历一块内存。

如果step_size是64字节的倍数，第一次执行内循环，是不会Cache Hit的，所有的读请求，都会到达内存层。但第二次执行内循环可就不一定了。

为了解决这个问题，在内循环中加一个Cache清理：

    for(j = 0; j < loop_number_1; j++)    {        for(i = 0, arr1 = arr; i < loop_number_2; i++)        {            k += *arr1;            __asm__ __volatile__            (                "clflush (%0)\n\t"                "lfence\n\t"                : :"r"(arr1) :            );            arr1 = (TYPE *)(((char *)arr1) + step_size);    // 地址向后加至少 64字节        }    }

测试程序片段2 -- 增加Cache清理

第6~11行，就是Cache的刷新指令：clflush，它会修改Cache Line头的标志，将Line改为Invidate（无效）状态。

如果Line是个Dirty的脏Line，也就是被修改过，clflush还会触发“写内存”操作，先写内存，再标记为无效Line。

如果你是其他x64平台CPU，如AMD，要查阅一下手册，找找AMD对应的指令是什么了。clflush是Intel平台的指令。

第9行的lfence指令，是为了“挡住”后续指令。因为CPU是乱序执行的，这里的lfence可以保证clflush先执行。这一块放在Cache系列中再详细讨论吧。

好了，测试程序就到这儿了。简单吧，后面我再把完整的代码粘上来。

还有，在开始测试前，一定要按照内存基础知识（十二）-- 如何得到精确的流量数据中的步骤，关闭指定Core的内存预取。详细的参阅第12篇中，这里不多说了。

下面，就要查看CPU手册了，得到MC中BG层流量计数器的编号。

我还以Intel至强CPU为例，MC中BankGroup流量如图1所示：

图1 可在内存基础知识（十一）中找到图1 URL

图1中是 RANK0 中 BG 0~3的流量计数器，event保持不变，都是0xB0，umask分别是0x11~0x14。

单是从这些计数器的文档中，就能看出不少信息了。比如这里umask取值范围在0x11~0x14间，说明针对BG的流量计数器有4个。那么，这款CPU 内存控制器所支持的Chip中，BG数量最多4个。

你要是插上条每Chip 8个BG的内存条，是点不亮这台服务器的。

图1是RANK 0中所有BG层的流量，下面再看看 RANK1 的BG层流量计数器：

图2

umask为0x11~0x14，和RANK 0相同，event为0xb1。

我不再截图了，每RANK中BG层流量计数器都相似，依次类推，RANK2的event为0xb2，RANK3的event为0xb3，等等。

RANK编号到7，RANK 0~7，也就是说，MC（内存控制器）中预留的RANK数量最多8个。

好，计数器编号都找出来了，光说不练假把事，开始闭环吧。

我的意思是，开始测试：

[root@rdma101 ff]# perf stat -C 0 -e LLC-load-misses,'uncore_imc_0/event=0xb0,umask=0x11/','uncore_imc_0/event=0xb0,umask=0x12/','uncore_imc_0/event=0xb0,umask=0x13/','uncore_imc_0/event=0xb0,umask=0x14/' ./mr3_2 0 0 64 10000 3Old CPU: 42==========Parent PID is 1003214==========PID is 1003215 -----------SUB Process at CPU: 0----------TSC: 8576744 0============================0 Performance counter stats for 'CPU(s) 0':            30,361      LLC-load-misses                                                         10,138      uncore_imc_0/event=0xb0,umask=0x11/                                               20,133      uncore_imc_0/event=0xb0,umask=0x12/                                                  358      uncore_imc_0/event=0xb0,umask=0x13/                                                  373      uncore_imc_0/event=0xb0,umask=0x14/                                          0.006184890 seconds time elapsed[root@rdma101 ff]#