4. CPU 调度延迟分析：调度器、C-State、频率缩放、中断负载、RT线程抢占、Scheduling延迟

4.1 现象识别：Systrace 中的调度失调迹象

CPU 调度延迟在 Systrace 中的典型“指纹”是：一个任务已经处于 Runnable 状态（在调度跟踪中表现为橙色/红色区块或 Sched 与 wakeup 标记之间的 gap），但迟迟没有获得 CPU 时间片。具体可观察以下迹象：

• Sched 与 Wakeup 间 gap 大：选中任务后，查看 Scheduling wakeup latency 或 Runnable to Running 时间 > 20ms。
• Running 段短但间隔长：任务频繁被换出，每次 Running 时长 < 1ms，但 Sched 到下次 Running 间隔 > 50ms。
• CPU 频率过低：在延迟区间内，CPU 频率柱状图显示工作在最低档（如 300MHz），同时有 cpufreq 事件。
• 中断风暴集中在一个核：所有 irq / softirq 都扎堆在 CPU0，而目标任务被调度到该核上排队。
• RT 线程压制：发现 sched_rt_rq 或 RT 优先级任务连续运行 > 20ms，阻塞 CFS 任务。
• C-State 退出过长：在 idle 后首次调度前，有 cpu_idle: state=4 且 exit_latency > 10ms。

4.2 数据采集：抓取完整调度决策上下文

仅靠默认的 sched_switch 不够，必须开启调度器、频率、idle 和中断的细粒度 tracepoint。使用以下参数录制：

# 抓取典型调度延迟场景（以 Android 为例）
systrace.py --time=10 -o scheduling.html \
  sched freq idle irq power workq

# 或使用 atrace 直接指定
atrace --async_start --buffer_size 16384 \
  -t sched freq idle irq power workq gfx input view

# 确定延迟区间后，用 CLI 导出原始 atrace 文本
atrace --async_dump > /data/local/tmp/trace_raw.txt

在 Trace View 中增加以下的关键列（自定义显示）：

4.3 原因定位：调度延迟故障树排查表

使用以下故障树判断路径，依据 Systrace 事件逐层下钻定位根因：

结合故障树，按以下排查表逐个检验根因：

4.4 修复动作

根据定位到的具体分支执行修复：

• 频率缩放优化：修改 cpufreq 调速器从 interactive 切换为 schedutil；若系统不支持则调小 hispeed_freq 和 target_loads。示例：

# 切换到 schedutil（基于调度器提示的调频）
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# 调高通调频的响应性（interactive 调速器下）
echo "80 1000000:90 1600000:95" > /sys/devices/system/cpu/cpufreq/interactive/target_loads

• C-State 控制：限制深度 C-State 的可用性，减少退出延迟：

# 禁止进入 C-State 3 或更深（调试用）
echo 2 > /sys/module/intel_idle/parameters/max_cstate  # Intel
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state3/disable  # 通用

• 中断迁移：使用 smp_affinity 将高频率中断从目标核移走：

# 查询中断号（以 eth0 为例）
cat /proc/interrupts | grep eth0  # 获取 IRQ 号，如 48
# 将 IRQ 48 的亲和掩码设为 0x00000002（仅 CPU1）
echo 2 > /proc/irq/48/smp_affinity

• RT 任务隔离：移除非关键 RT 任务到特定小核，或使用 chrt 降低其优先级：

# 将 RT 任务的优先级降为 1（最弱）
chrt -r -p 1 $(pidof rt_task_name)
# 使用 cgroup/cpuset 将 RT 任务绑定到 CPU4-7
echo 0-3 > /dev/cpuset/rt/cpus

4.5 复测与验证

修改后必须重新抓取相同场景的 Systrace，并验证以下指标：

• Runnable to Running gap：目标任务的 Waiting for CPU 时间从原来的 > 20ms 下降到 < 3ms。
• 频率响应曲线：在负载启动后的 2ms 内频率从最低档升到最高档，且 schedutil 事件没有明显滞后。
• 中断分布：确认 irq_handler_entry 不再全部集中在 CPU0，而是均匀分散（如 CPU0 20%、CPU1 25%、CPU2 25%、CPU3 30%）。
• C-State 退出次数：在负载区间内不应看到深 C-State（state > 2）退出；若仍然出现，继续调高 pm_qos_resume_latency_us 限制。

# 验证中断分散情况
cat /proc/interrupts | head -n 10  # 检查第二列起 CPU 计数是否均衡

# 验证频率切换延迟（使用 trace 中的 time delta）
grep "sched_wakeup" /data/local/tmp/trace_raw.txt | head -n 20

4.6 预防与监控

在工程层面建立长期检查机制，避免同类延迟反复出现：

• 内核配置硬门控：在 defconfig 中强制开启 CONFIG_SCHEDUTIL、CONFIG_NO_HZ_FULL、CONFIG_IRQ_TIME_ACCOUNTING。
• 自动化回归脚本：每次 CI 跑性能测试时附带 trace-cmd record -e sched_switch -e cpu_frequency，并用脚本解析 sched_wakeup 延迟的 P95 百分位。
• 中断负载预警：在 dashborad 上监控 /proc/interrupts 的方差，如果某个核的中断次数超过其他核 2 倍则告警。
• RT 任务白名单：建立 RT 任务列表，所有人新增 RT 任务时需 Code Review 确认其优先级和 cpuset，防止误用 RT 破坏 CFS 响应性。