28

运行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（具有匹配perf版本）在不同的 Intel Core i5 和 i7 系统（Ivy Bridge 类型）上进行了尝试。他们都不支持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 的值。

4

3 回答 3

26

看起来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 架构性能监控事件 架构性能事件在 Intel Core Solo 和 Intel Core Duo 处理器中引入。基于英特尔酷睿微架构的处理器也支持它们。表 19-1 列出了可使用通用性能计数器和相关事件选择寄存器配置的预定义架构性能事件。

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

在此处输入图像描述

在此处输入图像描述

...现在是棘手的部分，您将UMask Value2 作为高 2 个十六进制数字，而Event Num4 十六进制数字硬件寄存器号的低 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中查看非架构硬件寄存器，这里列出的太多太多了，但我会列出一些：

在此处输入图像描述

于 2014-03-28T14:34:56.343 回答
15

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

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

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

对于英特尔 CPU，最简单的方法是使用来自英特尔开源 python 项目的ocperf包装器，该项目由 Andi Kleen “pmu-tools”托管在 github https://github.com/andikleen/pmu-tools并在 ML 中介绍：https:// /lwn.net/Articles/556983/和 Andi 的博客http://halobates.de/blog/p/245perf

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

ocperf还将支持旧版 linux 内核的每个硬件事件。它有自己的 tsv 或 json 格式的数据库，所有硬件事件及其代码位于https://download.01.org/perfmon/（在 pmu-tools 中有自动下载器），并且该数据库由 Intel 不断更新雇主。数据库格式记录在自述文件中：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，第二部分：toplev ”基于 Ahmad Yasin 的“TopDown”方法“如何使用 Top 调整应用程序- 微架构问题的向下表征和“自顶向下分析”。性能计数器永远不会丢失“

于 2014-04-30T17:18:55.513 回答
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_BACKENDNehalem、Xeon E7 和 SandyBridge，但不支持 IvyBridge。PERF_COUNT_HW_STALLED_CYCLES_FRONTEND不过，IvyBridge 支持。

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

于 2014-03-28T16:48:29.167 回答