Linux性能如何计算缓存引用和缓存未命中事件

Lou*_*sYe 5 cpu caching linux-kernel perf

我对发生的事情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%)

Run Code Online (Sandbox Code Playgroud)

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
Run Code Online (Sandbox Code Playgroud)

Had*_*ais 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)
Run Code Online (Sandbox Code Playgroud)

所有这些事件都记录在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中的硬件计数器读取的。

不,这是一个陷阱。他们不容易理解。