我对发生的事情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
Hadi Brais..
5
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)
所有这些事件都记录在Intel手册第3卷中。有关如何将perf事件映射到本机事件的更多信息，请参见：硬件缓存事件和perf，以及perf 如何使用非核心事件？。
但是perf如何计算cache-misses事件？据我了解，如果缓存未命中计数了CPU缓存无法处理的内存访问次数，那么它是否不应该等于LLC-loads-misses + LLC-store-misses？显然，在我的情况下，高速缓存未命中数比“最后一级高速缓存未命中数”高得多。
LLC-load-misses并且LLC-store-misses仅计算需求请求，但同时也计算可缓存和不可缓存请求。另一方面，同时cache-misses计算需求和推测性请求，但仅计算可缓存的请求。因此，没有必要一个大于另一个。
缓存引用也有同样的困惑。它比L1-dcache-loads低得多，比LLC-loads + LLC-stores高得多
只能保证它cache-reference大于，cache-misses因为前者无论请求是否错过L3都对请求进行计数。之所以会变L1-dcache-loads大，cache-reference是因为它比正常情况大，这是因为源于内核的加载通常仅在您具有加载指令时发生，并且由于许多程序都显示了缓存局部性。但是由于硬件预取，不一定总是如此。
L1- *和LLC- *事件很容易理解，因为我知道它们是从CPU中的硬件计数器读取的。
不，这是一个陷阱。他们不容易理解。
1> Hadi Brais..：
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)
所有这些事件都记录在Intel手册第3卷中。有关如何将perf事件映射到本机事件的更多信息，请参见：硬件缓存事件和perf，以及perf 如何使用非核心事件？。
但是perf如何计算cache-misses事件？据我了解，如果缓存未命中计数了CPU缓存无法处理的内存访问次数，那么它是否不应该等于LLC-loads-misses + LLC-store-misses？显然，在我的情况下，高速缓存未命中数比“最后一级高速缓存未命中数”高得多。
LLC-load-misses并且LLC-store-misses仅计算需求请求，但同时也计算可缓存和不可缓存请求。另一方面，同时cache-misses计算需求和推测性请求，但仅计算可缓存的请求。因此，没有必要一个大于另一个。
缓存引用也有同样的困惑。它比L1-dcache-loads低得多，比LLC-loads + LLC-stores高得多
只能保证它cache-reference大于，cache-misses因为前者无论请求是否错过L3都对请求进行计数。之所以会变L1-dcache-loads大，cache-reference是因为它比正常情况大，这是因为源于内核的加载通常仅在您具有加载指令时发生，并且由于许多程序都显示了缓存局部性。但是由于硬件预取，不一定总是如此。
L1- *和LLC- *事件很容易理解，因为我知道它们是从CPU中的硬件计数器读取的。
不，这是一个陷阱。他们不容易理解。
京公网安备 11010802041100号