解读Perf日志：为何L2缺失周期数低于对应停顿数？

你采集的Perf数据如下：

FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.CYCLES_L1D_MISS     128  sample          847972.191                 #/op
FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.CYCLES_L2_MISS      128  sample            2715.740                 #/op
FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.CYCLES_L3_MISS      128  sample             469.392                 #/op
FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.STALLS_L1D_MISS     128  sample            9839.128                 #/op
FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.STALLS_L2_MISS      128  sample            4534.397                 #/op
FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.STALLS_L3_MISS      128  sample             816.202                 #/op
FloatMatrixMatrixMultiplication.mmBaseline:CYCLE_ACTIVITY.STALLS_TOTAL        128  sample           11711.435                 #/op

首先明确Intel CPU这两个性能事件的核心定义：

• CYCLE_ACTIVITY.CYCLES_L2_MISS：统计CPU处于等待L2缓存缺失请求完成状态的总周期数
• CYCLE_ACTIVITY.STALLS_L2_MISS：统计因L2缓存缺失导致流水线停顿的事件总次数

你看到的STALLS_L2_MISS大于CYCLES_L2_MISS，核心原因是这两个指标的统计维度完全不同，并非“停顿次数×平均等待周期=总周期”的简单关系，你的认知盲区在于混淆了**“停顿事件计数”和“阻塞周期计数”**，具体拆解如下：

• 乱序执行的重叠效应
  现代CPU是乱序执行架构，当L2缺失请求发出后，CPU不会完全停滞，而是会调度执行其他不依赖该缺失数据的指令。此时，虽然流水线可能因L2缺失触发多次停顿事件（比如指令队列阻塞、执行单元等待），但这些停顿事件都发生在同一个CPU周期内——CPU在这个周期里并没有完全空闲，而是在处理其他指令，因此CYCLES_L2_MISS只统计CPU真正无法推进关键路径的周期数，而STALLS_L2_MISS会把所有相关的停顿事件都计数，最终导致停顿次数多于阻塞周期数。

• 停顿事件的多阶段统计
  STALLS_L2_MISS会统计流水线不同阶段因L2缺失引发的停顿：比如前端取指阶段因L2缺失导致指令无法供给的停顿，后端执行阶段因数据依赖L2缺失的停顿。一次L2缺失可能同时触发多个阶段的停顿事件，但这些事件都消耗同一个等待周期，因此停顿次数会累加，而周期数只算一次。

• 超线程的资源复用
  如果你的CPU开启了超线程，当一个线程因L2缺失停顿，另一个线程可以在同一CPU周期内占用执行资源。此时CYCLES_L2_MISS只统计停顿线程的等待周期，但STALLS_L2_MISS会统计该线程的所有停顿事件，而这些事件对应的周期被另一个线程利用，所以从停顿线程的角度看，多个停顿事件可能重叠在同一个物理周期里，导致STALLS计数高于CYCLES。

结合你的数据计算：2715.740 / 4534.397 ≈ 0.6，意味着平均每个L2停顿事件只占用了0.6个CPU周期，这完全符合乱序执行下CPU资源复用的特性——CPU在等待L2数据时并没有完全闲置，因此停顿事件的计数不会和阻塞周期数一一对应。

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