Linux 进程调度器的工作原理解析

linux进程调度器按实时优先于普通、同级按vruntime最小原则选择下一个进程：实时进程（SCHED_FIFO/RR/DEADLINE）独占调度优先权；普通进程由CFS通过红黑树取最小vruntime节点实现长期公平。

进程调度器怎么决定“下一个该谁上 CPU”

Linux 不是随机挑一个进程来跑，而是按优先级+公平性双重逻辑筛选。核心原则是：实时进程（SCHED_FIFO/SCHED_RR/SCHED_DEADLINE）永远优先于普通进程；同属普通进程时，CFS 调度器通过 vruntime（虚拟运行时间）决定谁更“饿”。vruntime 越小，说明这个进程实际分到的 CPU 时间越少，就越该被调度——它被维护在红黑树最左端，调度器直接取树头节点，O(log n) 时间完成选择。

• 每个 CPU 有独立的运行队列 Struct rq，里面分两个子队列：rt_rq（放实时进程）和 cfs_rq（放普通进程）
• 调度器按 sched_class 优先级顺序调用：先调 rt_sched_class 查 rt_rq，没活干才轮到 fair_sched_class 查 cfs_rq
• stop_sched_class 是隐藏 Boss，只用于迁移线程或 CPU 热插拔等内核关键操作，用户态进程根本碰不到

为什么改 nice 值不总能立刻见效

因为 nice 只影响 CFS 中的权重计算，不改变进程类别，也不影响实时进程。它的作用路径是：nice → load.weight → vruntime 增长速率。负 nice（如 -10）让进程获得更高权重，vruntime 增长得慢，更容易被选中；正 nice（如 +15）则相反。

• nice 范围是 -20 到 19，但普通用户只能调高（即设为 0–19），只有 root 才能设负值
• 改完 nice 后，进程不会“插队”，只是下次调度周期里获得更大/更小的 CPU 时间份额
• 对已绑定到某 CPU 的实时进程（如用 taskset -c 0 + chrt -f 50 启动），nice 完全无效——它只作用于 SCHED_NORMAL 类进程

CFS 调度器里的“时间片”其实不存在

很多人误以为 CFS 和老式轮转法一样靠固定时间片切进程，其实它压根不维护时间片。CFS 动态计算每个进程的“理想运行时间”，公式近似为：ideal_time = (cpu_period × weight) / total_weight。这个值随就绪进程数、权重变化实时浮动——所以你看到 top 里 %CPU 波动剧烈，不是调度器不准，而是它本就不承诺“均分毫秒级时间片”。

• 默认 sysctl -w kernel.sched_latency_ns=6000000（6ms），这是 CFS 尝试在一个调度周期内调度完所有可运行进程的目标窗口
• 当就绪进程太多（比如 > 80 个），CFS 会自动缩短单次运行时间，避免某个进程长期得不到响应
• 不要手动调小 kernel.sched_min_granularity_ns 来“提高响应”，这反而会加剧上下文切换开销，实测可能让吞吐下降 10%+

实时进程抢占普通进程的边界在哪

实时进程能立即抢占普通进程，但不能抢占另一个更高优先级的实时进程，也不能抢占内核临界区（比如正在执行自旋锁保护的代码）。最关键的是：实时进程一旦开始运行，就会一直跑到自己主动让出（如 sleep、阻塞 I/O）或被更高优先级实时进程打断为止——没有“时间片用完强制切走”这回事。

• 用 chrt -f 99 启动的 FIFO 进程，若进入死循环且不 yield，会彻底霸占所在 CPU，连内核线程都可能被饿死
• SCHED_RR 有隐含时间片（默认 100ms），超时后自动移到同优先级队列尾部，但依然不保证其他普通进程能插进来——只要还有同优先级 RR 进程就绪，它就继续轮
• 检查是否真被抢占：用 perf sched latency -s max 看最高调度延迟，若 > 100μs 且集中在某进程，大概率是它没 yield 或绑核太死

CFS 的公平是“长期统计意义下的公平”，不是“每毫秒都平均”；实时调度的确定性依赖你完全掌控进程行为——这两点一旦混淆，调优就容易南辕北辙。