为什么perf stat显示“stalled-cycles-backend”为 <not supported> ？

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，硬件，内核或用户空间软件才能看到这个值？

目前在RHEL上使用Linux 3.12 for x86_64，在不同的Intel Core i5和i7系统（Ivy Bridge类型）上使用匹配的“perf”版本。 他们都没有支持陷入停滞的周期后端。

更多信息：

$ 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

编辑：刚试用AMD Phenom II X6 1045T CPU，在Ubuntu 12.04下使用Linux 3.2（32位） - 这里它确实显示了停滞循环前端和停滞循环后端的值。

Answer 1

看起来尚未更新perf以了解Ivy Bridge支持的所有性能监视事件。 幸运的是，有一个通用的，虽然繁琐的界面，允许您访问完整的性能监视事件列表。 当我快速看一下时，我没有在列表中看到stalled-cycles-backend ，但也许我错过了，或者他们可能已经将所有可能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

......拥有你最终进入的网址

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第三代INTEL®CORE™处理器的性能监控事件第三代Intel®Core ™处理器和Intel Xeon处理器E3-1200 v2产品系列基于Intel微体系结构代码名称Ivy Bridge。 它们支持表19-1中列出的体系结构性能监视事件。 表19-5中列出了处理器内核中的非架构性能监视事件。 表19-5中的事件适用于具有以下值的DisplayIDamily_DisplayModel编码的CPUID签名的处理器：06_3AH。

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

19.1架构性能监控事件架构性能事件在Intel Core Solo和Intel Core Duo处理器中引入。 基于英特尔酷睿微体系结构的处理器也支持它们。 表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了解非架构硬件寄存器，其中列表太多了，但我会列出一些：

Answer 2

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

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

要将事件名称与perf无需手动转换为原始事件ID（如amdn在其答案中所述 ），您可以使用perfmon2（ libpfm4 ; examples文件夹）中的转换器脚本showevtinfo和check_events ，如文章“ 如何监控完整文件”中所述。范围的CPU性能事件 “由Bojan Nikolic http://www.bnikolic.co.uk/blog/hpc-prof-events.html提供 。 perfmon2了解AMD和Intel CPU，并用C / C ++编写

对于Intel CPU的最简单的方法是使用ocperf包装在perf由安迪Kleen的来自英特尔的开源Python项目在GitHub上托管“PMU工具” https://github.com/andikleen/pmu-tools这里介绍ML： HTTPS ：//lwn.net/Articles/556983/和Andi的博客http://halobates.de/blog/p/245

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

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

对于Sandy Bridge / Ivy Bridge或Haswell以及内核3.10或更新版本，您还可以使用“ toplev.py -tools”中的toplev.py脚本来调查性能。 以下是其作者Andi Kleen的描述， http ://halobates.de/blog/p/262 “ pmu-tools，第二部分：toplev ”基于Ahmad Yasin的“ TopDown”方法“ 如何使用顶部调整应用程序- 微架构问题的下降特征和“ 自上而下的分析”。 永远不会失去性能指标 “

Answer 3

刚发现Re：perf，x86：添加部分剩余的haswell PMU功能 ：

> 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支持PERF_COUNT_HW_STALLED_CYCLES_BACKEND的Nehalem处理器，至强E7和SandyBridge的，但不是IvyBridge的。 PERF_COUNT_HW_STALLED_CYCLES_FRONTEND是支持IvyBridge的，虽然。

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