perf观测到页表遍历周期升高但总执行周期稳定的原因咨询

你观测到的指标矛盾本质是对dTLB_load_misses.walk_active事件的计数规则存在认知偏差，结合Intel Skylake架构的硬件资源设计逻辑，这个现象完全符合CPU的正常行为，不存在perf计数错误。 #

先明确两个测试事件在Xeon Gold 6142上的准确定义 #

• cycles（对应底层硬件事件cpu_clk_unhalted.thread）：线程私有计数，统计当前被监测的应用占用逻辑核心、逻辑核心处于非停机状态的总时钟周期，不会统计核心被其他线程占用、或当前线程不占用执行资源的周期。你已经关闭了睿频，核心频率固定，这个计数的基准是完全稳定的。
• dTLB_load_misses.walk_active：核心级共享计数，统计当前物理核心上的页表遍历硬件（PMH）处于工作状态的总周期，两个关键特性直接决定了它不会和cycles线性相关：
  • PMH是物理核心的共享硬件单元，服务本核心两个超线程的所有页表遍历请求，计数累加时不会区分遍历请求是哪个线程触发的。
  • PMH的页表遍历是完全异步的后台操作，不会阻塞CPU的乱序执行流水线。只有当程序执行到必须依赖本次遍历结果的指令时，才会产生流水线停顿，把延迟折算到应用的cycles计数里，其余遍历延迟都会被CPU的指令级并行能力掩盖。

观测现象的具体解释 #

为什么dTLB_load_misses.walk_active会显著升高 #

同插槽运行的单线程内存绑定应用，会争抢整个CPU插槽的共享硬件资源：L3缓存带宽、内存控制器带宽、内存总线IO周期。
PMH执行页表遍历时，需要逐级从内存读取PML4、PDPT、PD、PT四级页表项，内存带宽被高负载的内存绑定应用抢占后，单次页表项的读取延迟会明显上升，直接拉长单次页表遍历的总耗时。哪怕待测应用本身触发的dTLB load miss数涨幅不高（你贴的样例数据里dTLB-load-misses从1.76亿涨到2.29亿，涨幅30%），乘以被拉长的单次遍历耗时，就会出现walk_active周期数的明显上涨，部分场景下涨幅达到50%属于正常表现。
另外你贴的perf结果中每个事件后都标注了~66%的监测占比，说明你同时开启的性能事件数超过了CPU物理性能计数器的上限，perf是通过轮询采样+比例缩放计算的最终数值，本身存在一定统计误差，也会放大部分场景下的指标涨幅。

为什么总cycles稳定甚至略有下降 #

首先，PMH的后台遍历周期不会1:1转化为应用的执行周期。你测试的wc程序本身存在大量指令级并行空间：文件读取、文本分词、字符计数逻辑之间有大量无依赖指令，PMH后台处理页表遍历的时候，CPU流水线完全可以并行执行其他无依赖指令，只要遍历延迟没有卡到程序执行的关键路径，就不会带来应用cycles的上涨。
其次你贴的两组数据中，cycles从1869亿降到1845亿，降幅仅1.2%，对应执行时间从9.257s降到9.243s，完全在正常测试波动范围内。出现微幅下降的原因也很简单：内存绑定应用虽然占用了部分内存带宽，但同时也会把L3缓存中长期不被访问的冷数据替换出去，待测应用的热工作集在L3中的占比反而略有提升，带来了极小幅的性能改善，属于典型的测试噪声，不具备统计显著性。 #

内容的提问来源于stack exchange，提问作者Mohammad Siavashi