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

Running 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

Why is 停滞周期后端显示“不支持”？我需要什么样的 CPU、硬件、内核或用户空间软件才能看到该值？

目前在 RHEL 上使用 Linux 3.12 for x86_64 尝试过此操作，并匹配perf版本，在不同的 Intel Core i5 和 i7 系统（Ivy Bridge 类型）上。他们都不支持停滞周期后端.

更多信息：

$ 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

Edit:刚刚在 AMD Phenom II X6 1045T CPU 上尝试过这个，在 Ubuntu 12.04 和 Linux 3.2（32 位）下 - 这里它确实显示了两者的值停滞的周期前端 and 停滞周期后端.

好像perf尚未更新以了解 Ivy Bridge 支持的所有性能监控事件。幸运的是，有一个通用的（尽管很麻烦）界面允许您访问性能监控事件的完整列表。我没看到stalled-cycles-backend当我快速浏览一下时，它就在列表中，但也许我错过了，或者也许他们已经通过所有可能阻碍后端的不同事件将其分解了。

我们从

perf list --help

...显示以下内容NOTE

    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 中的事件适用于具有 DisplayFamily_DisplayModel 编码的 CPUID 签名且具有以下值的处理器：06_3AH。

...因此对于architectural您需要的事件 表 19-1

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

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

...现在是棘手的部分，你采取UMask Value作为上面 2 个十六进制数字和Event Num是要赋予的 4 个十六进制数字硬件寄存器号的低 2 个十六进制数字perf stat.

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 的非架构硬件寄存器，其中的寄存器太多了，这里无法列出，但我只列出一些：