PAPI L1_MISS原生事件计数器结果异常技术咨询

问题梳理 #

你在双NUMA节点的Skylake处理器上，用PAPI统计L1缓存访问时遇到了以下异常场景：

• 实验流程：主线程绑定NUMA1初始化并刷新数组缓存，5个绑定NUMA2的线程只读数组，之后主线程再次遍历数组并统计缓存事件
• 核心异常：
  1. MEM_LOAD_RETIRED.L1_MISS仅统计到56次，远低于预期的~100000
  2. MEM_INST_RETIRED.ALL_LOADS（100095）与L1_HIT+L1_MISS+FB_HIT之和（224）严重不符
  3. 当NUMA2线程改为修改数组时，主线程的L1_MISS恢复正常（99818）

原因分析 #

结合Skylake硬件特性、PAPI事件定义和NUMA缓存一致性协议，异常的核心原因可归纳为以下几点：

1. MEM_LOAD_RETIRED.L1_MISS的触发条件限制

Skylake架构中，这个原生事件仅统计需要从L2缓存或内存获取数据的退休加载指令。当NUMA2线程只读数组后，缓存行在NUMA2的L2/L3处于Shared状态，主线程（NUMA1）读取时会通过MESIF协议直接从NUMA2的缓存转发数据——这种跨NUMA的缓存转发操作，被硬件归类为“共享缓存层级命中”，而非传统的L1 miss，因此不会被该事件统计。
而当NUMA2线程修改数组时，缓存行变为Modified状态，主线程读取必须触发缓存行回写+重新加载，这个过程会明确触发L1 miss，所以计数恢复正常。

2. MEM_LOAD_RETIRED.FB_HIT的特殊计数场景

你看到的55次FB_HIT（Fill Buffer Hit），大概率是主线程读取时，部分缓存行的一致性请求还在Fill Buffer中处理，加载指令直接命中了Fill Buffer中的待返回数据。这类操作不会被统计为L1 miss，但会被计入FB_HIT，同时还有大量加载操作命中了L3共享缓存，这部分未被监控的事件导致ALL_LOADS与子事件之和不匹配。

3. L1D.REPLACEMENT的合理性验证

禁用预取器后，L1D.REPLACEMENT的结果（100246）接近数组大小是合理的：主线程读取时，L1缓存中原来的有效缓存行已经被NUMA2的操作置为Invalid，必须加载新的缓存行，因此触发了大量替换操作。启用预取时该事件会统计预取触发的替换，所以此时结果不可信，这点你的判断是正确的。

4. 指令计数的额外开销

MEM_INST_RETIRED.ALL_LOADS的数值（100095）比数组大小多95，是因为循环中还包含对循环变量i的加载、栈上临时变量tmp的操作等额外加载指令，属于正常现象。

解决建议 #

针对这个异常，你可以尝试以下几种方案：

1. 使用更精准的硬件原生事件

放弃PAPI的抽象事件，直接使用Skylake的原生事件统计L1缓存缺失：

• 比如L1D_CACHE.MISSES（对应硬件事件编码0x81D0，需参考Intel SDM确认），这个事件直接统计L1D缓存的所有缺失，包括跨NUMA缓存转发的场景
• 用papi_event_info工具查看PAPI事件对应的硬件编码，确认是否和你预期的统计范围一致

2. 强制刷新NUMA1的缓存

在主线程开始统计前，用clflush或clflushopt指令手动刷新数组的所有缓存行，确保L1缓存中没有有效副本：

for(int i=0; i < arr_size; i++){
    clflush(&array[i]);
}

这样主线程读取时必须从远程NUMA或内存获取数据，确保L1 miss被正确统计。

3. 结合perf工具交叉验证

用perf stat工具监控相同的缓存事件，对比PAPI的结果，确认是PAPI的事件映射问题还是硬件统计特性：

perf stat -e cache-misses,L1-dcache-load-misses,L1-dcache-loads ./your_program

如果perf的结果符合预期，说明PAPI的事件映射存在偏差，需要调整PAPI的事件选择。

4. 主动触发缓存状态转换

在主线程读取前，通过prefetchw指令标记数组为写意向，强制缓存行状态转换，确保读取操作触发明确的L1 miss：

for(int i=0; i < arr_size; i++){
    prefetchw(&array[i]);
}

这会让主线程读取时必须重新加载缓存行，避免跨NUMA共享缓存的影响。

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