为什么较新的Intel CPU在后端停止时不支持性能计数器？

Question

我正在使用内存预取来应对内存延迟。英特尔的某些（旧）CPU支持性能计数器，用于计算CPU在等待内存（stalled-cycles-backend）时浪费的周期。英特尔E5-2690。

在较新的CPU（例如Gold 6230和Gold 6226）上，我找不到此计数器。还有另一种方法可以计算CPU在等待内存控制器加载缓存行时浪费的周期吗？

Answer 1

perf称为“ stalled-cycles-backend”的事件是一个“通用”事件，在不同处理器型号上实现方式有所不同。很难找到这些定义，但是在CentOS 7.6内核源代码中，这些定义位于“ arch / x86 / events / intel / core.c”中。对于Sandy Bridge（Xeon E5-26xx），定义为事件0xB1，Umask 0x01，INV = 1，CMASK = 1。在英特尔架构软件开发人员手册第3卷第19章（文档325384-071,2019年10月）中查找此事件时，表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卷的第1页上的第2页上的第1部分指出，如果CMASK为零，则将忽略INV，因此，这实际上是计算已执行的Uop总数，而不是未执行Uop的周期。 （在运行完全相同内核的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

Answer 2

stalled-cycles-frontend仅在Nehalem，Westmere，Sandy Bridge和Ivy Bridge上受支持。它已映射到所有这些微体系结构上的event 0x0e, umask=0x01, inv=1, cmask=1。 Nehalem，Westmere和Sandy Bridge支持stalled-cycles-backend。在前两个中，它映射到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（Intel）在this线程中说，event=0xb1, umask=0x01, inv=1, cmask=1在Ivy Bridge上不受（正式）支持，并且列出事件的手册中的表已过时。因此，IvB不支持stalled-cycles-backend。但是根据手册V3（2019年5月）的表19-15，仍在IvB中列出。它还在Broadwell和更高版本中列出，但在Haswell中未列出。但是，《 Performance Monitoring事件手册》确实将其列出给Haswell。也许是Haswell的越野车？我不知道。

根据另一个thread，从哈斯韦尔开始，这两个事件似乎已被完全抛弃，有利于自上而下的方法的第一层次循环分解。