Linux不存在“流水线利用率”这一标准概念，top、vmstat、sar等命令仅提供用户态、内核态、空闲、I/O等待等宏观时间占比，无法反映CPU微架构层面的取指、译码、执行等流水线阶段效率；需用perf工具结合PMU采集cycles、instructions等硬件事件并计算IPC来间接评估。
Linux 没有“流水线利用率”这个标准概念，也不存在系统级命令直接输出 CPU 流水线（pipeline）的利用率数据。这是硬件微架构层面的指标，普通用户态工具无法直接观测。
为什么 top、mpstat 等命令不显示流水线利用率
top、vmstat、sar 等工具读取的是内核暴露的统计接口（如 /proc/stat），它们只提供宏观调度级指标：用户态时间（us）、空闲时间（id）、IO等待（wa）等。这些是软件可见的“时间占比”，不是 CPU 内部取指、译码、执行、回写等阶段的吞吐瓶颈分析。
- CPU 流水线深度、分支预测失败率、指令级并行度（ILP）等，属于微架构性能事件（performance events）
- 需要通过
perf工具配合硬件 PMU（Performance Monitoring Unit）采集，且依赖具体 CPU 型号支持的事件（如cycles、instructions、branch-misses、uops_issued.any） - 即使采集到原始事件计数，也需要人工计算“有效指令/周期”或“uops retired / cycles”等比值，才能间接反映流水线填充效率
想评估流水线效率，实际能做的只有 perf 采样
如果你真在排查低 IPC（Instructions Per Cycle）问题，比如一段代码跑得慢但 %us 不高，可以这样用 perf：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 先确认内核启用了性能事件：
cat /proc/sys/kernel/perf_event_paranoid应 ≤ 2（否则非 root 无法采集） - 对目标进程采样关键事件：
perf record -e cycles,instructions,branch-misses,uops_retired.retire_slots -p <pid></pid> - 生成报告看 IPC：
perf report --sort=comm,ipc—— 这里的IPC列就是“instructions / cycles”，低于 1.0 通常说明流水线停顿严重 - 进一步定位原因：
perf report -F overhead,symbol查看哪些函数贡献了最多branch-misses或stalled-cycles-frontend
别把 load average 或 %idle 当成流水线指标
很多人误以为 uptime 显示的 load average 高，或 top 里 %wa 高，就代表“CPU 流水线堵了”。其实完全不是一回事：
-
load average是运行队列长度的指数衰减平均值，反映的是任务调度压力，和硬件流水线无关 -
%wa表示 CPU 在等磁盘/网络完成，此时核心可能处于 idle 状态，流水线根本没在工作 - 真正流水线利用率低的表现是：CPU 频率拉满、
%us很高，但实际吞吐远低于理论峰值（比如 16 核 CPU 跑满才 20GIPS，而标称可达 80GIPS）
流水线利用率不是 Linux 系统管理员日常监控项，而是芯片工程师或 HPC 性能调优人员在做微架构级分析时才会深挖的细节。你看到的所有“CPU 使用率”命令，本质上都是在看“谁占用了 CPU 时间”，而不是“CPU 内部是否高效运转”。
