4. perf sched latency：调度延迟分析
perf sched latency 是分析内核调度延迟的核心工具。它通过记录调度事件（sched:sched_switch、sched:sched_wakeup 等），统计每个任务从“被唤醒”到“实际获得 CPU 执行”之间的时间差，即 调度延迟（Schedule Latency）。本节将详细解释输出字段的含义，并指导如何识别高延迟调度问题。
4.1 调度延迟的基本概念
调度延迟（也称为唤醒延迟）定义为：
- 唤醒时间点：任务被其他任务或中断唤醒的时刻（sched_wakeup 事件）。
- 执行时间点：任务实际被调度器选中，切换到 CPU 上执行的时刻（sched_switch 事件中的 next 任务）。
- 延迟 = 执行时间点 - 唤醒时间点。
关键理解：调度延迟反映了调度器对任务唤醒的响应速度。延迟越高，说明任务在就绪队列中等待的时间越长，可能影响交互式应用的流畅性或实时任务的截止时间。
4.2 运行 perf sched latency
使用以下命令记录并分析调度延迟：
# 记录调度事件（默认 10 秒）
sudo perf sched record -- sleep 10
# 分析并输出延迟统计
sudo perf sched latency
输出示例（部分截取）：
------------------------------------------------------------------------------------------------------------------
Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | Maximum delay at |
------------------------------------------------------------------------------------------------------------------
ksoftirqd/0 | 0.123 ms | 12 | 0.008 ms | 0.045 ms | 12345.678901234
chrome:1234 | 456.789 ms | 345 | 0.234 ms | 12.345 ms | 12346.789012345
Xorg:567 | 89.012 ms | 89 | 0.056 ms | 1.234 ms | 12345.901234567
python3:901 | 12.345 ms | 23 | 0.789 ms | 8.901 ms | 12347.012345678
------------------------------------------------------------------------------------------------------------------
TOTAL: | 558.269 ms | 469 | 0.154 ms | 12.345 ms |
------------------------------------------------------------------------------------------------------------------4.3 输出字段详细解释
| 字段 | 含义 | 分析价值 |
|---|---|---|
| Task | 任务名称（进程名:线程ID） | 识别具体哪个任务存在延迟问题 |
| Runtime ms | 任务在采样期间累计占用的 CPU 时间（毫秒） | 结合延迟判断任务是否频繁被抢占 |
| Switches | 任务被调度进/出的总次数 | 切换次数多可能意味着频繁争用 |
| Average delay ms | 所有调度延迟的平均值（毫秒） | 反映整体调度响应水平 |
| Maximum delay ms | 采样期间出现的最大单次调度延迟（毫秒） | 识别极端延迟尖峰 |
| Maximum delay at | 最大延迟发生时的系统时间戳（秒.纳秒） | 便于关联系统日志或其他事件 |
4.4 标准偏差（Stddev）的重要性
虽然 perf sched latency 默认不直接输出标准偏差，但我们可以通过 -s 选项或结合 perf script 计算。标准偏差衡量延迟的波动程度：
- 低标准偏差：延迟稳定，调度行为可预测。
- 高标准偏差：延迟波动大，存在间歇性高延迟，对实时性要求高的任务影响显著。
注意：平均延迟低并不代表系统健康。如果标准偏差很大，说明存在偶发的高延迟抖动，这对音频/视频播放、工业控制等场景可能是致命的。
4.5 如何识别高延迟调度
以下方法可以帮助你快速定位高延迟调度问题：
- 关注 Maximum delay 列：找出延迟最大的任务，记录其
Maximum delay at时间戳。 - 对比 Average delay 与 Maximum delay：如果最大值远大于平均值（例如 10 倍以上），说明存在严重的延迟尖峰。
- 结合 Runtime 和 Switches：一个 Runtime 很短但 Switches 很多的任务，可能频繁被更高优先级任务抢占，导致延迟累积。
- 使用时间戳关联其他事件：在
Maximum delay at时刻，检查系统日志、中断负载、其他 perf 事件（如perf sched trace）来定位根因。
实战案例：假设发现
chrome:1234 的 Maximum delay 达到 12.345 ms，而 Average delay 仅为 0.234 ms。此时应：
- 检查该时间点是否有大量磁盘 I/O 或网络中断。
- 使用
perf sched trace查看该任务的具体调度序列。 - 分析是否存在 CPU 绑定（CPU affinity）导致任务只能在部分 CPU 上运行，而其他 CPU 空闲。
4.6 高延迟的常见原因
| 原因 | 表现 | 排查方向 |
|---|---|---|
| CPU 过载 | 多个任务争用同一 CPU，就绪队列变长 | 检查 CPU 使用率、运行队列长度（/proc/loadavg） |
| 中断/软中断过多 | 高优先级中断频繁抢占调度 | 查看 /proc/interrupts，使用 perf top 分析中断开销 |
| 锁竞争 | 任务在等待锁时被阻塞，唤醒后延迟增加 | 使用 perf lock 或 ftrace 跟踪锁事件 |
| CPU 亲和性设置不当 | 任务被限制在少数 CPU 上，导致负载不均 | 检查 taskset 或 cgroup 配置 |
| 调度器策略/优先级问题 | 低优先级任务被高优先级任务无限抢占 | 检查调度策略（SCHED_OTHER/FIFO/RR）和 nice 值 |
4.7 使用 perf sched latency -s 获取标准偏差
通过 -s 选项可以输出更详细的统计信息，包括标准偏差：
sudo perf sched latency -s
# 输出示例（部分）：
# Task | Runtime ms | Switches | Avg delay | Max delay | Stddev
# chrome:1234 | 456.789 | 345 | 0.234 | 12.345 | 1.892
# Xorg:567 | 89.012 | 89 | 0.056 | 1.234 | 0.123Stddev 解读：
- Stddev 接近 0：延迟非常稳定。
- Stddev 大于平均延迟：延迟波动剧烈，存在明显的长尾分布。
- Stddev 远小于最大延迟：最大延迟是偶发异常值，需要单独分析其触发条件。
最佳实践：在性能基线测试中，同时记录平均延迟和标准偏差。如果标准偏差在版本升级后显著增大，即使平均延迟不变，也说明调度稳定性下降，需要警惕。