有人知道性能统计结果中 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
最佳答案
理论:
让我们从这个开始:现在的 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% 的周期在前端停滞时，您不知道如何真正解释这一点。您可以将 >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
关于linux - 'perf stat' 结果中的停滞周期前端和停滞周期后端是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22165299/