“性能统计”结果中的停滞周期前端和停滞周期后端是什么？

Question 1

有人知道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

Question 2

理论：

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

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

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

指令被淘汰的周期（有用的工作）
在后端花费的周期（已浪费）
在前端花费的周期（已浪费）。

要使IPC为4，退休的周期数必须接近周期的总数。请记住，在此阶段，所有微操作（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

在性能方面，这通常不会发生。这是一个问题，因为当您看到前端停滞了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

Question 3

要将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向RS发出的Uop数量。
设置Cmask = 1，Inv = 1，Any = 1，以计算该内核的停顿周期。

对于在我的系统上转换为event = 0xb1，umask = 0x01的停滞循环后端事件，同一文档说：

UOPS_DISPATCHED.THREAD：

计算每个周期每个线程要分配的微指令总数
设置Cmask = 1，INV = 1来计算失速周期。

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

Question 4

当管道在此期间不前进时，CPU周期将“停滞”。

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

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

Question 5

这些事件的作者认为，它们的定义很松散，并且可用可用的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的pmu-tools（toplev.py）中所做的那样：https : //github.com/andikleen/pmu-tools（源），http://halobates.de/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.

提交了引入停滞循环前端和停滞循环后端事件的Commit，而不是原始的Universal 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执行代码时的条件，但其功能未得到充分利用。了解这种情况并进行分析是代码优化工作流的重要子任务。

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

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

后端的过度使用可能导致前端停滞，因此也必须引起注意。

确切的构成取决于程序逻辑和指令混合。

我们宽松地使用术语“停顿”，“前端”和“后端”，并尝试使用来自近似这些概念的特定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,