3、CPU调度延迟：CFS调度器、上下文切换与中断的真相
说到微秒级延迟，CPU调度这块是绕不开的硬骨头。我刚开始做低延迟系统时，总觉得代码写得够快就行。后来被线上问题狠狠教育了一回——明明逻辑很简单，延迟就是忽高忽低。查到最后，发现是调度器在捣鬼。
今天咱们就掰开揉碎，看看CFS调度器、上下文切换和中断处理，到底是怎么影响延迟的。
3.1 CFS调度器：公平背后的代价
Linux默认的CFS（完全公平调度器），设计目标是让每个进程都能公平地获得CPU时间。但公平，往往意味着延迟不可控。
CFS的核心是红黑树，每个进程有一个vruntime（虚拟运行时间）。调度器每次选vruntime最小的进程来运行。听起来很合理对吧？但问题在于——
关键点：CFS的调度周期默认是4ms到8ms。也就是说，一个进程最多可能等这么长时间才能被调度上。对于微秒级延迟的应用，这简直是灾难。
我遇到过的一个案例：一个实时音频处理程序，要求每500微秒处理一次数据。结果在CFS下，偶尔会被调度出去等上好几毫秒。音频直接出现爆音。
解决办法？说白了就两条路：
- 使用实时调度策略：SCHED_FIFO或SCHED_RR，优先级高于普通进程
- 绑核：把关键进程固定在某个CPU核心上，避免被迁移
代码示例，设置实时优先级：
#include <sched.h>
#include <stdio.h>
int main() {
struct sched_param param;
param.sched_priority = 99; // 最高实时优先级
// 设置为SCHED_FIFO策略
if (sched_setscheduler(0, SCHED_FIFO, ¶m) == -1) {
perror("sched_setscheduler failed");
return 1;
}
// 验证一下
int policy = sched_getscheduler(0);
printf("Current policy: %d (FIFO=%d)\n", policy, SCHED_FIFO);
// 你的延迟敏感代码
while (1) {
// 处理任务...
}
return 0;
}⚠️ 警告：设置实时优先级要小心。我曾经见过一个新手把所有进程都设成SCHED_FIFO，结果系统直接卡死——因为实时进程优先级太高，连shell都抢不到CPU。建议只对关键线程设置，并且优先级不要超过50。
3.2 上下文切换：看不见的开销
上下文切换，说白了就是CPU从一个进程切到另一个进程时，要保存当前状态、加载新状态。这个过程涉及寄存器保存、TLB刷新、缓存污染……
你想想看，一次上下文切换大概要花多少时间？
| 操作 | 耗时（典型值） |
|---|---|
| 同一进程内线程切换 | 0.5 - 2 微秒 |
| 不同进程间切换 | 1 - 5 微秒 |
| 涉及内核态切换 | 3 - 10 微秒 |
嗯，这里要注意：这些数字看起来不大，但如果你要求的是10微秒以内的延迟，一次上下文切换就吃掉了一半预算。
我记得有一次做金融交易系统，延迟要求是5微秒以内。我们用了各种手段：
- 把关键线程绑到独立核心上，避免被其他线程抢占
- 使用
isolcpus内核参数，让系统进程别来打扰 - 关闭CPU节能状态（C-states），避免唤醒延迟
效果很明显，上下文切换次数从每秒几万次降到了几乎为零。
💡 小技巧：用perf stat -e context-switches可以监控上下文切换频率。如果发现每秒超过1000次，你的延迟敏感应用就要小心了。
3.3 中断处理：优先级与延迟的博弈
中断，是硬件通知CPU有事要处理。但中断来了，CPU就得停下当前工作去响应。这对延迟敏感应用来说，是个大麻烦。
中断分两种：
- 上半部（top half）：紧急处理，关中断执行，必须快
- 下半部（bottom half）：可以慢慢处理，开中断执行
问题出在上半部。如果某个设备的中断处理程序写得不好，占用了太多时间，你的实时线程就只能干等着。
我曾经遇到一个网卡驱动，它的中断处理程序一次要处理几百个数据包，耗时超过100微秒。我们的实时控制线程每50微秒就要响应一次，结果经常被中断打断，延迟直接飙到200微秒以上。
怎么解决？
- 中断亲和性：把中断绑定到非实时核心上
- 使用NAPI：网卡中断合并，减少中断频率
- 线程化中断：把中断处理放到内核线程中，可被调度
设置中断亲和性的命令：
# 查看中断号
cat /proc/interrupts | grep eth0
# 将中断绑定到CPU核心2（掩码为0x04）
echo 04 > /proc/irq/<中断号>/smp_affinity核心思路：让中断和实时任务各占各的核心，互不干扰。说白了就是物理隔离。
3.4 一张图看懂CPU调度延迟
下面这张图，是我自己总结的CPU调度延迟全链路。从任务就绪到真正执行，每一步都可能引入延迟。
3.5 实战避坑指南
最后，分享几个我踩过的坑：
✅ 推荐做法：
- 用
taskset绑核，把关键线程固定到独立核心 - 设置
isolcpus内核参数，让系统进程远离你的核心 - 使用
chrt设置实时优先级，但别设太高
❌ 我曾经犯过的错：
- 把所有线程都设成SCHED_FIFO，结果系统卡死——shell都抢不到CPU
- 没关CPU节能状态，导致从C-state唤醒花了上百微秒
- 中断和实时线程绑在同一个核心上，互相干扰
嗯，CPU调度延迟这块，说白了就是「谁先跑、谁后跑、谁打断谁」的问题。理解了这三个要素，你就能针对性地优化。下一层，咱们聊聊内存访问延迟——那又是另一个故事了。
公众号:蓝海资料掘金营，微信deep3321