为什么 perf stat 将“stalled-cycles-backend”显示为 <不支持>？

Question

运行perf stat ls 显示：

Performance counter stats for 'ls':

          1.388670 task-clock                #    0.067 CPUs utilized          
                 2 context-switches          #    0.001 M/sec                  
                 0 cpu-migrations            #    0.000 K/sec                  
               266 page-faults               #    0.192 M/sec                  
           3515391 cycles                    #    2.531 GHz                    
           2096636 stalled-cycles-frontend   #   59.64% frontend cycles idle   
   <not supported> stalled-cycles-backend  
           2927468 instructions              #    0.83  insns per cycle        
                                             #    0.72  stalled cycles per insn
            615636 branches                  #  443.328 M/sec                  
             22172 branch-misses             #    3.60% of all branches        

       0.020657192 seconds time elapsed

为什么 stalled-cycles-backend 显示为“不支持”？我需要什么样的 CPU、硬件、内核或用户空间软件才能看到这个值？

目前在不同的 Intel Core i5 和 i7 系统（Ivy Bridge 类型）上使用 Linux 3.12 for x86_64 和匹配的perf 版本在 RHEL 上进行了此尝试。他们都不支持stalled-cycles-backend。

更多信息：

$ perf list | grep stalled
  stalled-cycles-frontend OR idle-cycles-frontend    [Hardware event]
  stalled-cycles-frontend OR cpu/stalled-cycles-frontend/ [Kernel PMU event]

$ ls /sys/devices/cpu/events/
branch-instructions  bus-cycles    cache-references  instructions  mem-stores
branch-misses        cache-misses  cpu-cycles        mem-loads     stalled-cycles-frontend

$ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
event=0x0e,umask=0x01,inv,cmask=0x01

编辑： 刚刚在带有 Linux 3.2（32 位）的 Ubuntu 12.04 下的 AMD Phenom II X6 1045T CPU 上进行了尝试 - 这里确实显示了两个 stalled-cycles-frontend 的值 和 stalled-cycles-backend。

Answer 1

perf（或其内核部分）未更新以支持您的 CPU，因此 perf 无法将通用事件名称“stalled-cycles-backend”映射到实际的硬件事件。

在这种情况下，查找事件名称会更容易；例如对于 Intel CPU - 来自 Intel 的优化手册 http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf（它按类型对事件进行分组并解释如何使用它们来测量各个部分）。 AMD 没有类似的文档。

要使用带有 perf 的事件名称而无需手动转换为原始事件 ID（如 amdn 在他的 answer 中所说），您可以使用来自 perfmon2 的转换器脚本 showevtinfo 和 check_events（libpfm4；示例文件夹），正如 Bojan Nikolic http://www.bnikolic.co.uk/blog/hpc-prof-events.html 的文章“如何监控所有 CPU 性能事件”中所述。 perfmon2 了解 AMD 和 Intel CPU，并用 C/C++ 编写

对于 Intel CPU，最简单的方法是使用 ocperf wrapper 而非 Intel 的开源 python 项目中的 perf在 ML 中：https://lwn.net/Articles/556983/ 和在 Andi 的博客中 http://halobates.de/blog/p/245

ocperf 了解英特尔优化手册中的所有英特尔事件名称。

ocperf 还将支持旧版 linux 内核的每个硬件事件。它有自己的 tsv 或 json 格式的数据库，所有硬件事件及其代码位于https://download.01.org/perfmon/（在 pmu-tools 中有自动下载器），并且该数据库由英特尔的雇主不断更新。数据库格式记录在自述文件中：https://download.01.org/perfmon/readme.txt

对于 Sandy Bridge/Ivy Bridge 或 Haswell，以及内核 3.10 或更高版本，您还可以使用“pmu-tools”中的 toplev.py 脚本 来调查性能。这是作者 Andi Kleen 的描述，http://halobates.de/blog/p/262“pmu-tools, part II: toplev”基于 Ahmad Yasin "How to Tune Applications Using a Top-Down Characterization of Microarchitectural Issues 和 "Top Down Analysis. Never lost with performance counters" 的“TopDown”方法

Answer 2

刚刚找到Re: perf, x86: Add parts of the remaining haswell PMU functionality：

> AFAICS backend stall cycles are documented to work on Ivy Bridge.

I'm not aware of any documentation that presents these events
as accurate frontend/backend stalls without using the full
TopDown methology (Optimization manual B.3.2)

所以 IIUC 停滞周期后端计数器在 Ivy Bridge 上太不可靠了，这就是内核开发人员决定不支持它们的原因。

果然，Linux 的 perf_event_intel.c 支持 Nehalem、Xeon E7 和 SandyBridge 的 PERF_COUNT_HW_STALLED_CYCLES_BACKEND，但不支持 IvyBridge。不过，IvyBridge 支持PERF_COUNT_HW_STALLED_CYCLES_FRONTEND。

所以我想没有办法在我当前的 CPU 上获取这个计数器 - 要么切换 CPU，要么使用邮件中提到的完整自上而下的方法（并描述了 here 和 here）

Answer 3

看起来perf 尚未更新以了解 Ivy Bridge 支持的所有性能监控事件。幸运的是，有一个通用的接口，虽然很麻烦，但它允许您访问性能监控事件的完整列表。当我快速浏览时，我没有在列表中看到 stalled-cycles-backend，但也许我错过了，或者他们可能已经将它分解为所有可能导致后端停止的不同事件。

我们开始

perf list --help

...显示以下注意

    1. Intel(R) 64 and IA-32 Architectures Software Developer's Manual
       Volume 3B: System Programming Guide
       http://www.intel.com/Assets/PDF/manual/253669.pdf

...用你最终进入的那个 URL 武装

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf

...你想要第 19.3 节

19.3 第三代性能监控事件 英特尔® 酷睿™ 处理器 第三代英特尔® 酷睿™ 处理器和英特尔至强处理器 E3-1200 v2 产品系列基于英特尔微架构代号 Ivy Bridge。它们支持表 19-1 中列出的架构性能监控事件。表 19-5 列出了处理器内核中的非架构性能监控事件。表 19-5 中的事件适用于 CPUID 签名为 DisplayFamily_DisplayModel 编码的处理器，其值如下：06_3AH。

...所以对于architectural 事件，您需要表 19-1

19.1 架构性能监控事件 英特尔酷睿 Solo 和英特尔酷睿双核处理器中引入了架构性能事件。基于英特尔酷睿微架构的处理器也支持它们。表 19-1 列出了可使用通用性能计数器和相关事件选择寄存器配置的预定义架构性能事件。

**表 19-1。建筑表演活动

...现在是棘手的部分，您将UMask Value 作为高 2 个十六进制数字，Event Num 是要提供给 perf stat 的 4 个十六进制数字硬件寄存器号的低 2 个十六进制数字.

perf stat --help

   -e, --event=
       Select the PMU event. Selection can be a symbolic event name (use
       perf list to list all events) or a raw PMU event (eventsel+umask) in
       the form of rNNN where NNN is a hexadecimal event descriptor.

...上面写着NNN，但你可以给它NNNN。让我们验证它是否有效，让我们向perf stat 询问缓存未命中作为符号事件名称和表 19-1 中的十六进制数字。为简单起见，我们将调用 date 命令。

$ perf stat -e r412e -e cache-misses date

Fri Mar 28 09:28:52 CDT 2014

Performance counter stats for 'date':

          2292 r412e                                                       
          2292 cache-misses                                                

   0.003322663 seconds time elapsed

$ 

如您所见，两者都报告了相同的数字，到目前为止一切都很好。现在我们进入表19-5 非架构硬件寄存器，其中太多太多，这里列出，但我会列出一些：