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

看起来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第三代INTEL®CORE™处理器的性能监测事件第三代英特尔®酷睿™处理器和英特尔至强处理器E3-1200 v2产品家族基于英特尔®微体系架构代号Ivy Bridge。 它们支持表19-1中列出的架构性能监视事件。 表19-5列出了处理器内核中的非架构性能监视事件。 表19-5中的事件适用于具有DisplayFamily_DisplayModel编码的CPUID签名的处理器，其值为以下值：06_3AH。

…所以你需要architectural事件表19-1

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

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（就像在他的答案中说的那样），您可以使用来自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来说，最简单的方法是在github https://github.com/andikleen/pmu-tools托管的Andi Kleen“pmu-tools”的英特尔开源python项目中使用ocperf wrapper ，并在这里介绍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中有自动下载程序），数据库不断更新雇主&#x3002; 数据库的格式记录在自述文件中： https ： //download.01.org/perfmon/readme.txt

对于Sandy Bridge / Ivy Bridge或Haswell以及3.10或更高版本的内核，还可以使用“ toplev.py -tools”中的toplev.py脚本来调查性能。 这里是来自其作者Andi Kleen的描述，基于Ahmad Yasin的“ TopDown”方法http://halobates.de/blog/p/262“pmu-tools ，第二部分：toplev ” 如何使用顶部调整应用程序微结构问题的自下而上特征与“ 自上而下”分析。 从来没有与性能柜台丢失 “

刚刚发现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支持Nehalem，Xeon E7和SandyBridge的PERF_COUNT_HW_STALLED_CYCLES_BACKEND，但不支持IvyBridge。 虽然IvyBridge支持PERF_COUNT_HW_STALLED_CYCLES_FRONTEND。

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