Intel Haswell平台工作负载内存带宽统计结果不一致问题问询

背景概述 #

使用Intel Core i7-4720HQ（Haswell）处理器，在系统空闲时执行以下命令统计目标进程的L3 miss到本地DRAM的读请求：

sudo perf stat -e offcore_response.all_data_rd.l3_miss.local_dram,offcore_response.all_code_rd.l3_miss.local_dram -p <PID>

针对两个工作负载的统计显示：KDevelop的L3 miss到DRAM的读请求次数是VLC的12倍以上；但通过PCM获取的系统级IMC带宽统计却显示VLC的总内存带宽远高于KDevelop，二者结果矛盾。

核心矛盾解释 #

1. 统计范围与对象完全不同 #

• Perf是进程级读请求统计：仅统计目标用户态进程触发的、L3 miss后到本地DRAM的读请求次数，完全不涉及内核进程访问、其他用户态进程访问、GPU DMA传输、所有写操作的带宽消耗；
• PCM是系统级全带宽统计：统计整个系统所有内存交互的总字节数，包括读写操作、内核/后台进程访问、DMA传输、缓存写回等全部行为。

VLC播放视频时，大量带宽消耗来自GPU的DMA帧传输、内核page cache的写回操作，这些都不会被Perf统计到目标进程的L3读miss中，但会被PCM计入总带宽；而KDevelop的内存访问几乎都是用户态进程主动发起的读请求，因此Perf统计的次数多，但总字节数（带宽）远低于VLC的系统级带宽。

2. 访问类型与数据粒度差异 #

• Perf统计的是请求次数，每个L3 miss请求对应64字节的缓存行（Haswell缓存行大小），但KDevelop的代码索引是随机访问大量小代码块，预取器效率极低，导致大量L3 miss请求，但单请求字节数固定；
• VLC处理的是连续流媒体数据，CPU/GPU预取器可以高效提前加载数据到缓存，大幅减少L3 miss次数，但单次预取或DMA传输的字节数远大于单缓存行，因此总带宽（字节数）更高，但Perf统计的miss次数少。

3. 写入操作的带宽占比 #

PCM统计的总带宽包含读写两部分：

• VLC的写入带宽高达3.75GB（空闲时仅0.35GB），这部分来自视频解码后的帧数据写入显存、临时文件写入、内核page cache回写等，完全不在Perf的读请求统计范围内；
• KDevelop的写入带宽仅0.6GB，几乎可以忽略，其内存访问以读为主。

这是导致PCM总带宽VLC远高于KDevelop的关键原因之一。

4. offcore_response计数器的统计局限性 #

Haswell的offcore_response计数器仅统计CPU核心发起的、未命中L3缓存的读请求，不包含：

• 内核态的内存访问（如page cache的管理操作）
• 缓存写回操作（写回DRAM的字节数会被PCM统计，但不会触发读miss）
• 非缓存访问（如直接IO绕过CPU缓存的操作）

VLC的很多内存访问属于上述范畴，因此Perf无法捕捉，但PCM会统计到对应的带宽消耗。

内容的提问来源于stack exchange，提问作者TheAhmad