RTC*_*222 2 linux performance profiling x86-64 perf
下面是一个代码块,perf record 标记为造成所有 L1-dcache 未命中的 10%,但该块完全是 zmm 寄存器之间的移动。这是 perf 命令字符串:
perf record -e L1-dcache-load-misses -c 10000 -a -- ./Program_to_Test.exe
Run Code Online (Sandbox Code Playgroud)
代码块:
Round:
vmulpd zmm1,zmm0,zmm28
VCVTTPD2QQ zmm0{k7},zmm1
VCVTUQQ2PD zmm2{k7},zmm0
vsubpd zmm3,zmm1,zmm2
vmulpd zmm4,zmm3,zmm27
VCVTTPD2QQ zmm5{k7}{z},zmm4
VPCMPGTQ k2,zmm5,zmm26
VPCMPEQQ k3 {k7},zmm5,zmm26
KADDQ k1,k2,k3
VCVTQQ2PD zmm2{k7},zmm0
VDIVPD zmm1{k7},zmm2,zmm28 ; Divide by 100
VPXORQ zmm2{k7},zmm2,zmm2
vmovupd zmm2,zmm1
VADDPD zmm2{k1},zmm1,zmm25
Run Code Online (Sandbox Code Playgroud)
对于该代码块,我使用其他 L1 度量(例如 l1d.replacement)得到了类似的结果。
我的问题是,一个仅是 zmm 寄存器移动的块如何会产生 L1 缓存未命中?我认为寄存器根本不会进入内存。事实上,最后一次内存访问是在该代码块之上的10条指令;其他9条指令都是寄存器到寄存器指令。
该事件L1-dcache-load-misses映射到L1D.REPLACEMENTSandy Bridge 和后来的微架构(或映射到较旧的微架构上的类似事件)。此事件不支持精确采样,这意味着样本可能指向无法生成采样事件的指令。(请注意,L1-dcache-load-misses当前任何 Atom 都不支持此功能。)
从在 Haswell+ 或 Silvermont+ 微架构上运行的 Linux 3.11 开始,可以通过指定满足以下两个条件的采样事件,使用事件指令指针捕获样本:
L1D.REPLACEMENT。在支持扩展 PEBS 的处理器上,只有 PEBS 事件的子集支持精确采样。mem_load_uops_retired.l1_miss:pp可以将事件指定给 Linux perf。发生此类事件时,当事件计数器溢出时,PEBS 硬件就会启动,这意味着它现在正在寻找尽早收集精确样本的机会。当至少有一条指令会在此时间窗口期间引发事件时,PEBS 硬件最终将由这些指令之一触发,并且偏向于高延迟指令。当触发PEBS的指令退出时,PEBS微码例程将执行并捕获PEBS记录,其中包含触发PEBS的指令的IP(与架构IP不同)等。perf 用于显示结果的指令指针 (IP) 就是该事件 IP。(我注意到,指向不可能导致该事件的指令的样本数量可以忽略不计。)
在较旧的微架构(Haswell 和 Silvermont 之前)上,还支持“pp”精确采样级别。这些处理器上的 PEBS 将仅捕获架构事件,该事件指向按程序顺序紧随 PEBS 触发指令之后的静态指令。如果可能的话,Linux perf 使用 LBR,其中包含源-目标 IP 对来确定捕获的 IP 是否是跳转的目标。如果是这种情况,它会将源 IP 作为事件 IP 添加到示例记录中。
一些微体系结构支持一个或多个具有更好采样分布的事件(更好的程度取决于微体系结构、事件、计数器以及计数器即将溢出时正在执行的指令)。在 Linux perf 中,如果支持的话,可以通过指定精确级别“ppp”来启用精确分发。