Linux perf 如何计算缓存引用和缓存未命中事件
How does Linux perf calculate the cache-references and cache-misses events
我对性能事件 cache-misses 和 L1-icache-load-misses,L1-dcache-load-misses,LLC-load-misses 感到困惑。当我尝试 perf stat 所有这些时，答案似乎并不一致：
%$: sudo perf stat -B -e cache-references,cache-misses,cycles,instructions,branches,faults,migrations,L1-dcache-load-misses,L1-dcache-loads,L1-dcache-stores,L1-icache-load-misses,LLC-loads,LLC-load-misses,LLC-stores,LLC-store-misses,LLC-prefetches ./my_app
523,288,816 cache-references (22.89%)
205,331,370 cache-misses # 39.239 % of all cache refs (31.53%)
10,163,373,365 cycles (39.62%)
13,739,845,761 instructions # 1.35 insn per cycle (47.43%)
2,520,022,243 branches (54.90%)
20,341 faults
147 migrations
237,794,728 L1-dcache-load-misses # 6.80% of all L1-dcache hits (62.43%)
3,495,080,007 L1-dcache-loads (69.95%)
2,039,344,725 L1-dcache-stores (69.95%)
531,452,853 L1-icache-load-misses (70.11%)
77,062,627 LLC-loads (70.47%)
27,462,249 LLC-load-misses # 35.64% of all LL-cache hits (69.09%)
15,039,473 LLC-stores (15.15%)
3,829,429 LLC-store-misses (15.30%)
L1-* 和 LLC-* 事件很容易理解，因为我可以看出它们是从 CPU.
中的硬件计数器读取的
但是perf如何计算cache-misses事件呢？根据我的理解，如果 cache-misses 计算 CPU 缓存无法提供的内存访问次数，那么它不应该等于 LLC-loads-misses + LLC-store-misses 吗？很明显，在我的例子中，cache-misses 比 Last-Level-Cache-Misses 数高得多。
同样的困惑发生在 cache-reference。它比 L1-dcache-loads 低得多，比 LLC-loads+LLC-stores
高得多
我的 Linux 内核和 CPU 信息：
%$: uname -r
4.10.0-22-generic
%$: lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz
Stepping: 9
CPU MHz: 885.754
CPU max MHz: 4200.0000
CPU min MHz: 800.0000
BogoMIPS: 7584.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
您感兴趣的内置 perf 事件映射到处理器上的以下硬件性能监视事件：
523,288,816 cache-references (architectural event: LLC Reference)
205,331,370 cache-misses (architectural event: LLC Misses)
237,794,728 L1-dcache-load-misses L1D.REPLACEMENT
3,495,080,007 L1-dcache-loads MEM_INST_RETIRED.ALL_LOADS
2,039,344,725 L1-dcache-stores MEM_INST_RETIRED.ALL_STORES
531,452,853 L1-icache-load-misses ICACHE_64B.IFTAG_MISS
77,062,627 LLC-loads OFFCORE_RESPONSE (MSR bits 0, 16, 30-37)
27,462,249 LLC-load-misses OFFCORE_RESPONSE (MSR bits 0, 17, 26-29, 30-37)
15,039,473 LLC-stores OFFCORE_RESPONSE (MSR bits 1, 16, 30-37)
3,829,429 LLC-store-misses OFFCORE_RESPONSE (MSR bits 1, 17, 26-29, 30-37)
所有这些事件都记录在英特尔手册第 3 卷中。有关如何将 perf 事件映射到本机事件的更多信息，请参阅： and 。
But how does perf calculate cache-misses event? From my understanding,
if the cache-misses counts the number of memory accesses that cannot
be served by the CPU cache, then shouldn't it be equal to
LLC-loads-misses + LLC-store-misses? Clearly in my case, the
cache-misses is much higher than the Last-Level-Cache-Misses number.
LLC-load-misses 和 LLC-store-misses 分别只计算在 L3 缓存中未命中的可缓存数据读取请求和 RFO 请求。 LLC-load-misses 还包括翻页阅读。两者都不包括硬件和软件预取。 （与Haswell相比的不同之处在于，某些类型的预取请求被计算在内。）
cache-misses 还包括未命中 L3 缓存的预取请求和代码获取请求。所有这些事件只计算核心发起的请求。它们包括来自 uops 的请求，无论是否最终退休，也无论响应的来源如何。我不清楚提升为需求的预取是如何计算的。
总的来说，我认为 cache-misses 总是大于 LLC-load-misses + LLC-store-misses 而 cache-references 总是大于 LLC-loads + LLC-stores .
The same confusion goes to cache-reference. It is much lower than
L1-dcache-loads and much higher then LLC-loads+LLC-stores
只保证cache-reference大于cache-misses，因为前者无论是否错过L3都会计算请求。 L1-dcache-loads 大于 cache-reference 是正常的，因为内核发起的加载通常仅在您有加载指令时发生，并且由于许多程序都显示缓存局部性。但由于硬件预取，情况并非总是如此。
The L1-* and LLC-* events are easy to understand, as I can tell they
are read from the hardware counters in CPU.
不，这是一个陷阱。它们并不容易理解。
我对性能事件 cache-misses 和 L1-icache-load-misses,L1-dcache-load-misses,LLC-load-misses 感到困惑。当我尝试 perf stat 所有这些时，答案似乎并不一致：
%$: sudo perf stat -B -e cache-references,cache-misses,cycles,instructions,branches,faults,migrations,L1-dcache-load-misses,L1-dcache-loads,L1-dcache-stores,L1-icache-load-misses,LLC-loads,LLC-load-misses,LLC-stores,LLC-store-misses,LLC-prefetches ./my_app
523,288,816 cache-references (22.89%)
205,331,370 cache-misses # 39.239 % of all cache refs (31.53%)
10,163,373,365 cycles (39.62%)
13,739,845,761 instructions # 1.35 insn per cycle (47.43%)
2,520,022,243 branches (54.90%)
20,341 faults
147 migrations
237,794,728 L1-dcache-load-misses # 6.80% of all L1-dcache hits (62.43%)
3,495,080,007 L1-dcache-loads (69.95%)
2,039,344,725 L1-dcache-stores (69.95%)
531,452,853 L1-icache-load-misses (70.11%)
77,062,627 LLC-loads (70.47%)
27,462,249 LLC-load-misses # 35.64% of all LL-cache hits (69.09%)
15,039,473 LLC-stores (15.15%)
3,829,429 LLC-store-misses (15.30%)
L1-* 和 LLC-* 事件很容易理解，因为我可以看出它们是从 CPU.
但是perf如何计算cache-misses事件呢？根据我的理解，如果 cache-misses 计算 CPU 缓存无法提供的内存访问次数，那么它不应该等于 LLC-loads-misses + LLC-store-misses 吗？很明显，在我的例子中，cache-misses 比 Last-Level-Cache-Misses 数高得多。
同样的困惑发生在 cache-reference。它比 L1-dcache-loads 低得多，比 LLC-loads+LLC-stores
我的 Linux 内核和 CPU 信息：
%$: uname -r
4.10.0-22-generic
%$: lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz
Stepping: 9
CPU MHz: 885.754
CPU max MHz: 4200.0000
CPU min MHz: 800.0000
BogoMIPS: 7584.00
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
您感兴趣的内置 perf 事件映射到处理器上的以下硬件性能监视事件：
523,288,816 cache-references (architectural event: LLC Reference)
205,331,370 cache-misses (architectural event: LLC Misses)
237,794,728 L1-dcache-load-misses L1D.REPLACEMENT
3,495,080,007 L1-dcache-loads MEM_INST_RETIRED.ALL_LOADS
2,039,344,725 L1-dcache-stores MEM_INST_RETIRED.ALL_STORES
531,452,853 L1-icache-load-misses ICACHE_64B.IFTAG_MISS
77,062,627 LLC-loads OFFCORE_RESPONSE (MSR bits 0, 16, 30-37)
27,462,249 LLC-load-misses OFFCORE_RESPONSE (MSR bits 0, 17, 26-29, 30-37)
15,039,473 LLC-stores OFFCORE_RESPONSE (MSR bits 1, 16, 30-37)
3,829,429 LLC-store-misses OFFCORE_RESPONSE (MSR bits 1, 17, 26-29, 30-37)
所有这些事件都记录在英特尔手册第 3 卷中。有关如何将 perf 事件映射到本机事件的更多信息，请参阅：
But how does perf calculate cache-misses event? From my understanding, if the cache-misses counts the number of memory accesses that cannot be served by the CPU cache, then shouldn't it be equal to LLC-loads-misses + LLC-store-misses? Clearly in my case, the cache-misses is much higher than the Last-Level-Cache-Misses number.
LLC-load-misses 和 LLC-store-misses 分别只计算在 L3 缓存中未命中的可缓存数据读取请求和 RFO 请求。 LLC-load-misses 还包括翻页阅读。两者都不包括硬件和软件预取。 （与Haswell相比的不同之处在于，某些类型的预取请求被计算在内。）
cache-misses 还包括未命中 L3 缓存的预取请求和代码获取请求。所有这些事件只计算核心发起的请求。它们包括来自 uops 的请求，无论是否最终退休，也无论响应的来源如何。我不清楚提升为需求的预取是如何计算的。
总的来说，我认为 cache-misses 总是大于 LLC-load-misses + LLC-store-misses 而 cache-references 总是大于 LLC-loads + LLC-stores .
The same confusion goes to cache-reference. It is much lower than L1-dcache-loads and much higher then LLC-loads+LLC-stores
只保证cache-reference大于cache-misses，因为前者无论是否错过L3都会计算请求。 L1-dcache-loads 大于 cache-reference 是正常的，因为内核发起的加载通常仅在您有加载指令时发生，并且由于许多程序都显示缓存局部性。但由于硬件预取，情况并非总是如此。
The L1-* and LLC-* events are easy to understand, as I can tell they are read from the hardware counters in CPU.
不，这是一个陷阱。它们并不容易理解。