为什么较新的英特尔 CPU 不支持停滞周期后端的性能计数器？答案

【问题标题】：Why do newer Intel CPUs not suppert performance counter for stalled-cycles-backend?为什么较新的英特尔 CPU 不支持停滞周期后端的性能计数器？
【发布时间】：2020-02-26 16:30:55
【问题描述】：

我正在使用内存预取来解决内存延迟问题。 Intel 的一些（较旧的）CPU 支持性能计数器，用于计算 CPU 因等待内存而浪费的周期 (stalled-cycles-backend)，例如英特尔E5-2690。

在较新的 CPU（例如Gold 6230 和Gold 6226）上，我找不到这个计数器。还有其他方法可以计算 CPU 等待内存控制器加载缓存线所浪费的周期吗？

【问题讨论】：

Skylake 的resource_stalls.any 柜台可能正是您想要的。不确定这是否完全等同于 Sandybridge 上的 stalled-cycles-backend。
哦，如果你特别想要内存停顿，还有更具体的事件；在perf list 输出中搜索您要查找的内容。例如来自我的 SKL（Skylake 客户端）mem_load_retired.l3_miss 专门计算负载 insns（不是周期）。或者cycle_activity.stalls_l3_miss 计数L3 缓存未命中需求负载突出时执行停止。这与没有交付微指令的周期不同，只是没有执行，所以我认为即使 ROB / RS 未满也可以计数。
谢谢彼得，我会试试cycle_activity.stalls_l3_miss。

标签： memory intel performancecounter perf intel-pmu

【解决方案1】：

stalled-cycles-frontend 仅在 Nehalem、Westmere、Sandy Bridge 和 Ivy Bridge 上受支持。它在所有这些微架构上都映射到event 0x0e, umask=0x01, inv=1, cmask=1。 stalled-cycles-backend 在 Nehalem、Westmere 和 Sandy Bridge 上受支持。在前两个上，它映射到event=0xb1, umask=0x3f, inv=1, cmask=1。在 SnB 上，它映射到 event=0xb1, umask=0x01, inv=1, cmask=1。

从内核 v4.6-rc1 开始，如果当前处理器不支持这些事件中的任何一个，它不会显示在 perf stat 的输出中。在早期版本的内核中，它会显示<not supported>。

Andi Kleen（英特尔）在this 线程中表示，Ivy Bridge 不（官方）支持event=0xb1, umask=0x01, inv=1, cmask=1，并且列出该事件的手册中的表格已过时。这就是 IvB 不支持 stalled-cycles-backend 的原因。但根据手册 V3（2019 年 5 月）的表 19-15，它仍然为 IvB 列出。它也被列在 Broadwell 及以后，但不是 Haswell。但是，性能监控事件手册确实为 Haswell 列出了它。也许它在 Haswell 上有问题？我不知道。

根据另一位 thread 的说法，这两个事件似乎已从 Haswell 开始完全放弃，转而支持自上而下方法的第一级循环分解。

【讨论】：

我在第 3B 卷的 Broadwell 表中有一个 Kaby Lake 和许多计数器，这些计数器没有出现在 Kaby Lake 表上工作（当我使用驱动程序对应用程序进行基准测试时，我直接编程PMC EVTSELs 使用 wrmsr，然后使用 rdpmc - rdpmc) 并向具有相同事件但不同 Umask 的受支持计数器显示不同但可行的值。例如 UOPS_ISSUED.ANY 和 FLAGS_MERGE。它们始终具有比 rdpmc 指令 (4*2) 之间的 uop 数量大得多的不同值，因为 2 个不同的 PMC 对同一运行的受支持和不受支持的计数器进行基准测试
我的意思是 UOPS_RETIRED.ALL 不是 UOPS_ISSUED.ANY。看看imgur.com/sicAwoT

【解决方案2】：

perf 称为“stalled-cycles-backend”的事件是一个“通用”事件，在不同的处理器型号上实现方式不同。这些定义很难找到，但在 CentOS 7.6 内核源代码中，定义位于“arch/x86/events/intel/core.c”中。对于 Sandy Bridge (Xeon E5-26xx)，定义为 Event 0xB1, Umask 0x01, INV=1, CMASK=1。在 Intel Architectures SW Developer's Manual（文档 325384-071，2019 年 10 月）的第 3 卷第 19 章中查找此事件，表 19-3 显示在 Skylake Xeon（和 Cascade Lake Xeon）上，此事件的含义相同： “计算没有从每个线程的预留站 (RS) 分派微指令的周期。”

如果您想了解计数的内容，我建议您不要使用这些“通用”事件。在内核源代码中寻找定义，或者构建一个测试程序来读取执行程序的实际 MSR 是很痛苦的。我今天测试的第一个实际上是错误的——在 Xeon E5 v4 系统上，事件“uops_executed.core_cycles_none”被编程为事件 0xb1，Umask 0x02，INV=1，但 CMASK 未设置为 1。第 18.2 节SWDM 第 3 卷的第 3 卷说如果 CMASK 为零，则忽略 INV，因此这实际上计算了执行的总 Uops，而不是没有执行 Uops 的周期。（相同的事件在运行完全相同内核的 SKX 盒子上被正确编程。）

在运行 Intel Memory Latency Tester 时计算总周期、未分派 Uop 的周期以及至少分派一个 Uop 的周期的示例：

perf stat -e r0043003c -e r01c301b1 -e r014301b1 ./mlc --idle_latency
  Intel(R) Memory Latency Checker - v3.7
  Command line parameters: --idle_latency 

  Using buffer size of 2000.000MiB
  *** Unable to modify prefetchers (try executing 'modprobe msr')
  *** So, enabling random access for latency measurements
  Each iteration took 182.4 core clocks (   87.1    ns)


 Performance counter stats for './mlc --idle_latency':

    91,815,806,587      r0043003c                                                   
    64,132,006,584      r01c301b1                                                   
    27,683,941,060      r014301b1                                                   

      14.587156882 seconds time elapsed

【讨论】：

cmask 事件 uops_executed.core_cycles_none 的缺席可能是一个错误，它似乎存在于 Broadwell 和更早版本。