Linux无法直接暴露流水线停顿，因其属纳秒级硬件行为，操作系统不可见；perf通过PMU事件（如uops_retired.retire_slots与uops_issued.any比值）间接定位停顿根源，需结合反汇编和微架构知识分析。
Linux 本身不直接暴露“流水线停顿”这种微架构级指标——它不是进程状态，也不是系统调用能返回的字段。你看到的 T（stopped）、D（uninterruptible）等状态，和 CPU 流水线里的 bubble 完全无关。
为什么 ps/top 看不到流水线停顿
流水线停顿（pipeline stall）是 CPU 硬件在指令执行过程中因数据依赖、分支预测失败或资源争用而插入的空周期，发生在纳秒级、每条指令内部，操作系统内核无法感知，更不会写入进程状态字段。你用 ps -eo pid,stat,comm 看到的 T 是进程被信号暂停（如 SIGSTOP），属于调度层行为，和硬件流水线无关。
- 进程状态
T：用户态主动暂停，可被SIGCONT恢复 - 流水线停顿：CPU 内部自动插入 bubble，对软件透明，无对应系统接口
- perf 采样到的
branch-misses或cache-misses是停顿的*间接诱因*，不是停顿本身
真正能定位流水线停顿的工具只有 perf + 硬件事件
Linux 下唯一可行路径是通过 perf 读取 CPU PMU（Performance Monitoring Unit）中的底层事件，再结合反汇编推断停顿位置。关键不是“看停顿”，而是“看导致停顿的根源”：
- 用
perf record -e cycles,instructions,branch-misses,cache-misses,uops_issued.any,uops_retired.retire_slots录制一段热点代码 -
perf script -F +brstackinsn输出带指令地址的采样流，配合objdump -d反汇编定位具体指令 - 重点关注：
uops_retired.retire_slots / uops_issued.any比值显著低于 1 → 存在大量未退休微操作，暗示流水线阻塞 - Intel CPU 可用
idq_uops_not_delivered.core（未送达核心的微操作数），直接反映前端阻塞程度
Tracy 和 perf 的区别：一个给开发者，一个给系统工程师
Tracy 能显示“指令级流水线停顿热图”，是因为它在运行时注入采样点、绑定硬件计数器、并内置了微架构指令数据库（如每条 mov 在 Skylake 上的端口占用和延迟）。但 Tracy 需要重新编译目标程序并链接其 profiler agent；而 perf 是系统级工具，无需改代码，但输出原始事件，需人工关联指令。
- Tracy：适合已知热点函数，想深挖某几行 C++ 对应的流水线行为
-
perf：适合快速筛查整个进程，发现异常高的l1d.replacement（L1 数据缓存替换）或idq.mite_uops（MITE 解码瓶颈） - 二者都不能告诉你“第 37 个 cycle 发生了 stall”，只能告诉你“这段代码附近 stall 概率极高”
别被“stalled-cycles-frontend/backend”误导
perf list 里确实有 stalled-cycles-frontend 和 stalled-cycles-backend，但它们是估算值，非精确计数：
- 前端停顿：通常由指令解码慢、分支预测失败、ITLB miss 引起
- 后端停顿：通常由 ALU 争用、Cache miss、Store buffer full 引起
- 这些事件在不同 CPU 微架构上含义差异极大（比如 AMD Zen3 没有
stalled-cycles-frontend），必须查对应 uarch 手册确认定义 - 数值为 0 不代表没停顿，可能是 PMU 未启用该计数器或内核未导出
真正难的不是采集数据，而是把 perf report 里一条 add %rax,%rbx 指令的高 cache-misses，和它前面三条 mov 是否构成 RAW 冒险联系起来——这需要手绘五级流水线时序图，或用 llvm-mca 模拟。硬件层的停顿，终究得回到指令序列和微架构特性里找答案。
