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

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类：

1. 指令退役的周期（有用的工作）
2. 在后端花费的周期（浪费）
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％的周期时 ，您不知道如何真正解释这一点。 您可以将> 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

根据英特尔文档SDM第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中实现） http：// www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf“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的toplev.py -tools（ toplev.py ）中所做的那样： https ： //github.com/andikleen/pmu-tools （source）， http ： toplev.py / blog / p / 262 （介绍）：

% 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提交：

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a

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执行代码但其功能未得到充分利用时的条件。 了解这些情况并分析它们是代码优化工作流程的重要子任务。

这两个事件都限制了性能：大多数前端停顿往往是由分支错误预测或指令获取高速缓存引起的，后端停顿可能是由各种资源短缺或低效的指令调度引起的。

前端停顿是更重要的：如果指令流没有保持，代码就无法快速运行。

过度使用的后端可能会导致前端失速，因此也必须密切关注。

确切的组成非常依赖于程序逻辑和指令混合。

我们松散地使用术语'stall'，'front-end'和'back-end'，并尝试使用来自特定CPU的最佳可用事件来近似这些概念。

抄送：Peter Zijlstra抄送：Arnaldo Carvalho de Melo抄送：Frederic Weisbecker链接： http ：//lkml.kernel.org/n/tip-7y40wib8n000io7hjpn1dsrm@git.kernel.org签名：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,