首页 文章

了解CYCLE_ACTIVITY . * Haswell性能监控事件

提问于
浏览 次
5

我正在尝试使用自上而下的微体系结构分析方法（TMAM）分析Intel Haswell CPU（英特尔®酷睿™i7-4900MQ）的执行情况，如Intel® 64 and IA-32 Architectures Optimization Reference Manual的第B.1和B.4章所述 . （如果需要，我将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 比 *_L1D_PENDING 大100倍甚至大1000倍，可能不是那样..是否分别以某种方式测量了档位/周期？但是有这个公式：

%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 . 但是这不能解决上面描述的问题 . ）那么如何解释呢？

edit: 我的操作系统：Ubuntu 14.04.3 LTS，内核：3.13.0-65-通用x86_64，性能版本：3.13.11-ckt26

intel performancecounter cpu-architecture cpu-cache perf

1 回答

  • 1

    我将从问题的第二部分开始，即 CYCLE_ACTIVITY.CYCLES_L2_PENDING 和 CYCLE_ACTIVITY.STALLS_L2_PENDING 如何分别大于 CYCLE_ACTIVITY.CYCLES_L1D_PENDING 和 CYCLE_ACTIVITY.STALLS_L1D_PENDING .

    首先，请注意 %L2_Bound 的公式来自英特尔优化手册的B.5节 . 该节的第一段说：

    本节介绍使用性能监视事件的各种性能调整技术 . 一些技术可以适用于其他微体系结构，大多数性能事件都是特定于英特尔微体系结构代码名称Sandy Bridge .

    我的第一个预感是预取与它有关（见我的comment） . 这一段使我朝着正确的方向前进;这些事件可能代表Sandy Bridge和Haswell的不同事物 . 这是他们在Haswell上的意思：

    CYCLE_ACTIVITY.CYCLES_L1D_PENDING：具有挂起的L1数据高速缓存未命中负载的周期 . CYCLE_ACTIVITY.CYCLES_L2_PENDING：具有挂起的L2未命中加载的周期 . CYCLE_ACTIVITY.STALLS_L1D_PENDING：由于L1数据高速缓存未命中加载而导致执行停顿 . CYCLE_ACTIVITY.STALLS_L2_PENDING：错过L2的负载数 .

    该手册还说L2的计数器只应在禁用超线程时使用 . 现在这是他们在Sandy Bridge的意思：

    CYCLE_ACTIVITY.CYCLES_L1D_PENDING：每个周期都有一个未决的需求加载此线程，递增1. CYCLE_ACTIVITY.CYCLES_L2_PENDING：每个周期都有一个MLC-miss挂起需求加载此线程，递增1. CYCLE_ACTIVITY.STALLS_L1D_PENDING：每个周期有一个未决的需求加载此线程并且没有调度uops，递增1. CYCLE_ACTIVITY.STALLS_L2_PENDING：每个周期都有一个MLC-miss挂起的需求加载，并且在该线程上没有调度uops，递增1 .

    有三个重要的区别：

    • 某些Haswell事件只有在禁用HT时才有效 . 即使启用了HT，所有SNB事件也都有效 .
      HSW上的

    • CYCLE_ACTIVITY.STALLS_L2_PENDING 计算L2处的负载未命中数，但在SNB上，它计算L2期间至少有一个需求负载未命中的周期数 .

    • HSW事件包括所有访问，而不仅仅是需求加载 . 相反，SNB事件仅发生在需求负载上 .

    在HSW上， CYCLE_ACTIVITY.CYCLES_L2_PENDING 可以大于 CYCLE_ACTIVITY.CYCLES_L1D_PENDING ，因为L1D预取器（和/或L2预取器）发出的未决挂起的负载取决于预取器是否为相同级别的高速缓存递增计数器 . 类似地，虽然它们计算不同的东西，但由于预取， CYCLE_ACTIVITY.STALLS_L2_PENDING 可能大于 CYCLE_ACTIVITY.STALLS_L1D_PENDING . 其他MMU缓存中的TLB预取和预取也可能影响HSW上的这些性能事件 . 另一方面，在SNB上，保证 CYCLE_ACTIVITY.STALLS_L2_PENDING < CYCLE_ACTIVITY.STALLS_L1D_PENDING ，这就是 %L2_Bound 公式在SNB上有效的原因 .

    就像我在评论中说的那样，禁用HT和/或prefetching可能会导致你的问题 .

    相关：When L1 misses are a lot different than L2 accesses… TLB related?

    关于问题的第一部分，即 CPU_CLK_UNHALTED.THREAD_P 如何小于 CYCLE_ACTIVITY.CYCLES_LDM_PENDING . 我能想到的一个解释是 CYCLE_ACTIVITY.CYCLES_LDM_PENDING 发生在从（某些）其他线程（特别是在同一物理内核）发出的负载上，而不仅仅是暂停的线程 . 我建议禁用HT，看看会发生什么 .

    回复于

相关问题