lar*_*ary 5 intel performancecounter cpu-architecture cpu-cache perf
我试图分析英特尔Haswell的CPU(英特尔®酷睿™i7-4900MQ)与自上而下的微架构分析方法(TMAM),在各章B.1和B.4所述,在执行英特尔®64和IA-32架构优化参考手册.(如果需要,我将B.4中描述的Sandy Bridge公式调整为Haswell Microarchitecture.)
因此,我使用Perf执行性能计数器事件测量.有些结果我不明白:
CPU_CLK_UNHALTED.THREAD_P < CYCLE_ACTIVITY.CYCLES_LDM_PENDING
这仅适用于少数测量,但仍然很奇怪.PMU计数是否会停止CYCLE_ACTIVITY.CYCLES_LDM_PENDING？
CYCLE_ACTIVITY.CYCLES_L2_PENDING> CYCLE_ACTIVITY.CYCLES_L1D_PENDING
和CYCLE_ACTIVITY.STALLS_L2_PENDING>CYCLE_ACTIVITY.STALLS_L1D_PENDING这适用于所有测量.当L1D高速缓存未命中时,负载会转移到L2高速缓存,对吧？因此早先错过L2的负载也错过了L1.这里没有计算L1指令高速缓存,但是它的大小*_L2_PENDING是100倍甚至1000倍*_L1D_PENDING,可能不是这样.是否分别以某种方式测量了档位/周期？但是有这个公式:
%L2_Bound =
(CYCLE_ACTIVITY.STALLS_L1D_PENDING - CYCLE_ACTIVITY.STALLS_L2_PENDING) / CLOCKS
因此CYCLE_ACTIVITY.STALLS_L2_PENDING< CYCLE_ACTIVITY.STALLS_L1D_PENDING假定(公式的结果必须为正).(这个公式的另一个原因是它可能应该CYCLES代替STALLS.但是这不能解决上面描述的问题.)那么如何解释呢？
编辑:我的操作系统:Ubuntu 14.04.3 LTS,内核:3.13.0-65-通用x86_64,性能版本:3.13.11-ckt26
我将从问题的第二部分开始，即 和CYCLE_ACTIVITY.CYCLES_L2_PENDING如何CYCLE_ACTIVITY.STALLS_L2_PENDING分别大于CYCLE_ACTIVITY.CYCLES_L1D_PENDING和CYCLE_ACTIVITY.STALLS_L1D_PENDING。
首先，请注意 的公式%L2_Bound来自英特尔优化手册的 B.5 节。该节的第一段说：
\n\n\n本节介绍使用性能监视事件的各种性能调整技术。某些技术可以普遍适用于其他微架构，大多数性能事件特定于代号为 Sandy Bridge 的英特尔微架构。
\n
我的第一预感是预取与此有关（请参阅我的评论）。这一段让我朝着正确的方向进一步前进；这些事件在 Sandy Bridge 和 Haswell 中可能代表不同的事物。以下是Haswell的含义：
\n\n\n\n\nCYCLE_ACTIVITY.CYCLES_L1D_PENDING： 具有挂起的 L1 数据缓存的周期\n 未命中加载。CYCLE_ACTIVITY.CYCLES_L2_PENDING：具有未决 L2\n 的循环未命中负载。CYCLE_ACTIVITY.STALLS_L1D_PENDING： 由于 L1 数据缓存未命中加载而导致执行停止。CYCLE_ACTIVITY.STALLS_L2_PENDING： 错过 L2 的\n 负载数。
\n
该手册还指出，L2 计数器仅应在禁用超线程时使用。现在这就是他们在桑迪桥上的意思：
\n\n\n\n\nCYCLE_ACTIVITY.CYCLES_L1D_PENDING：每个周期都有一个未命中\n 请求加载此线程，递增 1。
\n
\n CYCLE_ACTIVITY.CYCLES_L2_PENDING：每个周期都有一个MLC 未命中\n 未决请求加载此线程，递增 1。
\ n CYCLE_ACTIVITY.STALLS_L1D_PENDING：每个周期都有一个未命中的\n 请求加载此线程，并且没有调度 uops，递增 1。
\n CYCLE_ACTIVITY.STALLS_L2_PENDING：每个周期都有一个MLC 未命中\n 未决的请求负载，并且没有 uops在此线程上调度，增加\n 1。
存在三个重要的区别：
\n\nCYCLE_ACTIVITY.STALLS_L2_PENDING在 HSW 上，计算 L2 上的负载未命中数，但在 SNB 上，它计算在 L2 上至少存在一次需求负载未命中的周期数。在 HSW 上，由于 L1D 预取器（和/或 L2 预取器，取决于预取器是否递增同一级高速缓存的计数器）发出未决加载，因此CYCLE_ACTIVITY.CYCLES_L2_PENDING可以大于。CYCLE_ACTIVITY.CYCLES_L1D_PENDING同样，虽然它们计算不同的东西，但由于预取CYCLE_ACTIVITY.STALLS_L2_PENDING可能会比它们大。CYCLE_ACTIVITY.STALLS_L1D_PENDINGTLB 预取和其他 MMU 缓存中的预取也可能影响 HSW 上的这些性能事件。另一方面，在 SNB 上，保证CYCLE_ACTIVITY.STALLS_L2_PENDING< CYCLE_ACTIVITY.STALLS_L1D_PENDING，这就是该%L2_Bound公式在 SNB 上有效的原因。
正如我在评论中所说，禁用 HT 和/或预取可能会“解决”您的问题。
\n\n实际上，移动 Haswell 处理器的英特尔规格更新文档提到了两个影响的错误CYCLES_L2_PENDING：
CYCLES_L2_PENDING是仅对需求负载进行计数，但在 SMT 模式下可能计数不准确。CYCLES_L2_PENDING由于来自下一页预取器的请求，可能会过度计数。CYCLES_L2_PENDING我认为您可以通过禁用 SMT（在 BIOS 中或将其他逻辑核心置于睡眠状态）来最大限度地减少错误。另外，尽量不要触发NPP。这可以通过避免接近虚拟页末尾的位置来实现，在该位置下一页的转换尚未在 TLB 层次结构中。
相关：当 L1 未命中与 L2 访问有很大不同时\xe2\x80\xa6 TLB 相关？
\n\n关于问题的第一部分，即如何CPU_CLK_UNHALTED.THREAD_P小于CYCLE_ACTIVITY.CYCLES_LDM_PENDING。我能想到的一种解释是，这种CYCLE_ACTIVITY.CYCLES_LDM_PENDING情况发生在从（一些）其他线程（特别是在同一物理核心上）发出的负载，而不仅仅是停止的线程。Erratum HSM146 提到CYCLES_LDM_PENDING当逻辑核心不在 C0 时可能计数不准确，这解释了如何CPU_CLK_UNHALTED.THREAD_P小于CYCLES_LDM_PENDING。尽管规范更新文档没有提供任何解决方法，但禁用 HT 可能会消除这种不准确性。