问题描述
我对性能事件 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-存储未命中?显然，就我而言，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 如何使用 offcore 事件?.
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 如何计算缓存未命中事件?以我的理解，如果缓存未命中计算无法访问的内存访问次数由 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.
LLC-load-misses 和 LLC-store-misses 分别只计算在 L3 缓存中未命中的可缓存数据读取请求和 RFO 请求.LLC-load-misses 还包括用于页面遍历的读取.两者都不包括硬件和软件预取.(与 Haswell 不同的是，某些类型的预取请求被计算在内.)
LLC-load-misses and LLC-store-misses count only cacheable data read requests and RFO requests, respectively, that miss in the L3 cache. LLC-load-misses also includes reads for page walking. Both exclude hardware and software prefetching. (The difference compared to Haswell is that some types of prefetch requests are counted.)
cache-misses 还包括在 L3 缓存中未命中的预取请求和代码提取请求.所有这些事件只计算核心发起的请求.它们包括来自 uops 的请求，无论是否最终退出，也无论响应的来源如何.我不清楚如何计算提升为需求的预取.
cache-misses also includes prefetch requests and code fetch requests that miss in the L3 cache. All of these events only count core-originating requests. They include requests from uops irrespective of whether end up retiring and irrespective of the source of the response. It's unclear to me how a prefetch promoted to demand is counted.
总的来说，我认为 cache-misses 总是大于 LLC-load-misses + LLC-store-misses 和 cache-references 总是大于 LLC-loads + LLC-stores.
Overall, I think cache-misses is always larger than LLC-load-misses + LLC-store-misses and cache-references is always larger than LLC-loads + LLC-stores.
同样的混淆也适用于缓存引用.它远低于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 perf 如何计算缓存引用和缓存未命中事件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2