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 或绑核太死
