Question

有人知道在perf stat结果中 stalled-cycles-frontend 和 stalled-cycles-backend 的含义是什么？我在互联网上搜索但没有找到答案。感谢

$ sudo perf stat ls                     

Performance counter stats for 'ls':

      0.602144 task-clock                #    0.762 CPUs utilized          
             0 context-switches          #    0.000 K/sec                  
             0 CPU-migrations            #    0.000 K/sec                  
           236 page-faults               #    0.392 M/sec                  
        768956 cycles                    #    1.277 GHz                    
        962999 stalled-cycles-frontend   #  125.23% frontend cycles idle   
        634360 stalled-cycles-backend    #   82.50% backend  cycles idle
        890060 instructions              #    1.16  insns per cycle        
                                         #    1.08  stalled cycles per insn
        179378 branches                  #  297.899 M/sec                  
          9362 branch-misses             #    5.22% of all branches         [48.33%]

   0.000790562 seconds time elapsed

Answer 1

理论：

让我们从这开始：nowaday的CPU是超标量的，这意味着它们可以在每个周期（IPC）执行多个指令。最新的英特尔架构最多可以支持4个IPC（4个x86指令解码器）。我们不要将宏观/微观融合纳入讨论，以使事情复杂化：）。

通常，由于各种资源争用，工作负载未达到IPC = 4。这意味着 CPU浪费周期（指令数量由软件给出，CPU必须在尽可能少的周期内执行它们。）

我们可以将CPU花费的总周期分为3类：

指令退役的循环（有用的工作）
在后端花费的周期（浪费）
在前端花费的周期（浪费）。

要获得4的IPC，周期退休的数量必须接近总周期数。请记住，在此阶段，所有微操作（uOps）都从管道中退出并将其结果提交到寄存器/缓存中。在此阶段，您可以退休超过4 uOps，因为此数字由执行端口数量给出。如果您只有25％的周期退休4 uOps，那么您的整体IPC将为1。

后端停滞的周期是一种浪费，因为CPU必须等待资源（通常是内存）或完成长延迟指令（例如超越 - sqrt，倒数，划分等）。

在前端停滞的周期是一种浪费，因为这意味着前端不会通过微操作为后端提供信息。这可能意味着您在指令高速缓存中未命中，或者在微操作高速缓存中尚未解码的复杂指令。即时编译代码通常表达此行为。

另一个失速原因是分支预测未命中。这被称为糟糕的猜测。在那种情况下，uOps被发布但是它们被丢弃，因为BP预测错了。

在个人资料中实施：

你如何解释BE和FE停滞的周期？

不同的分析器在这些指标上有不同的方法。在vTune中，类别1到3加起来给出100％的周期。这种接合是合理的，因为要么你的CPU停止运转（没有uOps退休）要么它执行有用的工作（uOps）退休。点击此处：https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm

在perf中，这通常不会发生。这是一个问题，因为当您看到 125％的前端停滞在前端时，您不知道如何真正解释这一点。您可以将＆gt; 1指标与4个解码器相关联，但如果继续推理，则IPC将不匹配。

更好的是，你不知道问题有多大。 125％的东西是什么？那么#cycles意味着什么？

我个人对perf的BE和FE停滞周期看起来有点怀疑，希望这会得到解决。

通过调试此处的代码，我们可能会得到最终答案：http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c

Answer 2

要将perf导出的通用事件转换为可以运行的CPU文档原始事件：

more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend

它会显示类似

的内容

event=0x0e,umask=0x01,inv,cmask=0x01

根据Intel documentation SDM volume 3B（我有一个核心i5-2520）：

UOPS_ISSUED.ANY：

将RAT发出的Uops的每个周期增加到RS。
设置Cmask = 1，Inv = 1，Any = 1以计算此核心的停滞周期。

对于转换为event = 0xb1的stalled-cycles-backend事件，我的系统上的umask = 0x01，相同的文档说：

UOPS_DISPATCHED.THREAD：

计算每个周期每个线程要发送的uop总数
设置Cmask = 1，INV = 1以计算停顿周期。

通常，停顿的周期是处理器正在等待某些事情的周期（例如，在执行加载操作后要进行的存储）并且没有任何其他事情可做。此外，CPU的前端部分是负责获取和解码指令（将它们转换为UOP）的硬件，其中后端部分负责有效地执行UOP。

Answer 3

当管道在其中没有前进时，CPU周期“停滞”。

处理器流水线由许多阶段组成：前端是这些阶段的一组，负责提取和解码阶段，而后端执行指令。在前端和后端之间有一个缓冲区，所以当前者停滞不前时，后者仍然可以做一些工作。

取自http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/

Answer 4

根据这些事件的作者，他们松散地定义并且由可用的CPU性能计数器近似。据我所知，perf不支持根据几个硬件事件计算某些合成事件的公式，因此它不能使用英特尔优化手册中的前端/后端停顿绑定方法（在VTune中实现）{{3} }“B.3.2分层自上而下的性能表征方法”

%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N ); 
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ; 
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ; 
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ; 
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)

正确的公式可以与一些外部脚本一起使用，就像在Andi Kleen的pmu-tools（toplev.py）中完成的那样：http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf（来源），https://github.com/andikleen/pmu-tools（描述）：< / p>

% toplev.py -d -l2 numademo  100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE      Backend Bound:                      72.03%
    This category reflects slots where no uops are being delivered due to a lack
    of required resources for accepting more uops in the    Backend of the pipeline.
 .....
FE      Frontend Bound:                     54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.

提交了stalled-cycles-frontend和stalled-cycles-backend事件而不是原始的通用stalled-cycles：

http://halobates.de/blog/p/262

author  Ingo Molnar <mingo@el...>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <mingo@el...>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

perf事件：添加通用的前端和后端停顿循环事件定义   添加两个通用硬件事件：前端和后端停顿周期。

这些事件测量CPU执行代码时的条件   能力没有得到充分利用。了解这种情况和   分析它们是代码优化工作流程的一个重要子任务。

这两个事件限制了性能：大多数前端档位往往会造成   通过分支错误预测或指令获取cachemisses，后端   摊位可能由各种资源短缺或低效造成   指令调度。

前端档位更重要：代码无法快速运行   如果指令流没有保持。

过度使用的后端可能会导致前端停顿   还必须留意。

确切的构成是非常程序逻辑和指令组合   依赖

我们松散地使用术语'stall'，'front-end'和'back-end'   尝试使用来自特定CPU的最佳可用事件   近似这些概念。
     抄送：Peter Zijlstra   抄送：Arnaldo Carvalho de Melo   抄送：Frederic Weisbecker   链接：http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a   签名：Ingo Molnar

    /* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
-       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;

-   PERF_COUNT_HW_STALLED_CYCLES        = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_FRONTEND   = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_BACKEND    = 8,

在'perf stat'结果中，什么是停滞 - 循环 - 前端和停滞 - 循环 - 后端？

4 个答案: