Linux性能如何计算缓存引用和缓存丢失事件 [英] 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时，答案似乎不一致:
I am confused by the perf events cache-misses and L1-icache-load-misses,L1-dcache-load-misses,LLC-load-misses. As when I tried to perf stat all of them, the answer doesn't seem consistent:
%$: 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中的硬件计数器读取的.
The L1-* and LLC-* events are easy to understand, as I can tell they are read from the hardware counters in CPU.
但是perf如何计算cache-misses事件?据我了解，如果cache-misses计算CPU缓存无法处理的内存访问次数，那么它是否不等于LLC-loads-misses + LLC-store-misses?显然，对于我来说，cache-misses远高于Last-Level-Cache-Misses数.
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.
cache-reference也有同样的困惑.它远低于L1-dcache-loads，远高于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
我的Linux内核和CPU信息:
My Linux kernel and CPU info:
%$: 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事件将映射到处理器上的以下硬件性能监视事件:
The built-in perf events that you are interested in are mapping to the following hardware performance monitoring events on your processor:
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事件映射到本机事件的更多信息，请参见: perf如何使用非核心事件?.
All of these events are documented in the Intel manual Volume 3. For more information on how to map perf events to native events, see: Hardware cache events and perf and How does perf use the offcore events?.
但是perf如何计算cache-misses事件?据我了解， 如果高速缓存未命中计数无法访问的内存访问次数 由CPU缓存提供服务，那么它是否不应该等于 LLC-load-misses + LLC-store-misses?显然，就我而言 高速缓存未命中数比最后一级高速缓存未命中数"高得多.
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仅计算需求请求，但也计算可缓存和不可缓存请求.另一方面，cache-misses同时计算需求和推测性请求，但仅计算可缓存的请求.因此，没有必要一个大于另一个.
LLC-load-misses and LLC-store-misses count only demand requests but they also count both cacheable and uncacheable requests. On the other hand, cache-misses counts both demand and speculative requests but only the cacheable ones. So it's not necessary that one is larger than the other.
对缓存引用也有同样的困惑.它远低于 L1-dcache-loads和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是正常的，因为源于内核的加载通常仅在您具有加载指令时发生，并且由于许多程序都显示了缓存局部性.但是由于硬件预取，情况不一定总是如此.
It's only guaranteed that cache-reference is larger than cache-misses because the former counts requests irrespective of whether they miss the L3. It's normal for L1-dcache-loads to be larger than cache-reference because core-originated loads usually occur only when you have load instructions and because of the cache locality exhibited by many programs. But it's not necessarily always the case because of hardware prefetches.
L1- *和LLC- *事件很容易理解，据我所知 是从CPU中的硬件计数器读取的.
The L1-* and LLC-* events are easy to understand, as I can tell they are read from the hardware counters in CPU.
不，这是一个陷阱.他们不容易理解.
No, it's a trap. They are not easy to understand.
这篇关于Linux性能如何计算缓存引用和缓存丢失事件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
