每次面试被问”Linux 是怎么决定让哪个进程先跑的”,很多人支支吾吾说不清楚。
其实 Linux 的调度器设计思路极其优雅,核心思想用一句话就能说清楚:
让所有进程的”已运行时间”尽可能相等——谁运行最少,谁下一个跑。
这就是 CFS(Completely Fair Scheduler,完全公平调度器),Linux 2.6.23 起成为默认调度器,至今仍是大多数场景的主力。
本篇从”为什么需要 CFS”讲起,顺着原理一路讲到实际调优,让你一次搞懂。
一、旧调度器的问题:什么叫”不公平”?
Linux 2.6.23 之前用的是 O(1) 调度器——名字来自它选下一个进程的时间复杂度是 O(1)。
它的核心思路是:给每个进程一个固定时间片(比如 100ms),按优先级轮流跑。
听起来合理,但有几个根本问题:
1. 问题一:交互进程体验差
一个文本编辑器(交互进程)和一个编译任务(CPU 密集进程)优先级相同,各有 100ms 时间片轮流跑。用户按下键盘,编辑器最多要等 100ms 才响应——明显感觉到卡顿。
2. 问题二:优先级是拍脑袋的”魔法数字”
怎么决定给 nice=-5 的进程分配多少时间片?没有一个优雅的数学公式,都是经验值。优先级数目一多,调整极其复杂。
3. 问题三:CPU 使用率统计不准
O(1) 调度器用启发式算法猜一个进程是”交互型”还是”CPU 密集型”,猜错了就会调度错误。
CFS 彻底抛弃了”时间片”这个概念,用一个极其优雅的思路重新设计。
二、CFS 的核心思想:虚拟时钟
CFS 的核心概念叫 vruntime(virtual runtime,虚拟运行时间)。
每个进程都有一个 vruntime 值,表示它”在虚拟时钟里已经跑了多久”。
CFS 的选择规则只有一条:每次都选 vruntime 最小的进程运行。
- 运行时间越少的进程,vruntime 越小,越优先被选中
- 进程运行时,vruntime 持续增加
- 这样,所有进程的 vruntime 会趋于相等——公平!
但只有 vruntime,还不够解释优先级——凭什么 nice=-20 的进程要比 nice=19 的进程跑得更多?
三、nice 值与权重:vruntime 的增速不一样
CFS 用 权重(weight) 来实现优先级差异。
每个 nice 值对应一个权重,nice=0 的权重是 1024(基准值)。nice 每降 1,权重增加约 25%;nice 每升 1,权重减少约 20%。
关键公式:复制
vruntime 增量 = 实际运行时间 × (nice=0的权重 / 该进程的权重)1.
这意味着:高优先级(低 nice 值)进程的权重大,同样跑了 10ms,它的 vruntime 增加得少——下次被选中的概率更高,实际上获得了更多 CPU 时间。
同样跑了 10ms,高优先级进程(nice=-5)的 vruntime 只增加了 3.3ms,而低优先级进程(nice=+5)的 vruntime 增加了 30.5ms。vruntime 增加越慢,在红黑树里排名越靠左,被选中的频率越高——这就是优先级的本质。
四、红黑树:CFS 的”选人”数据结构
CFS 把所有可运行进程放进一棵红黑树里,以 vruntime 为键排序。
红黑树的最左节点,就是 vruntime 最小的进程——每次调度,直接取最左节点,O(log n) 时间,但内核缓存了最左节点指针,实际是 O(1)。
整个 CFS 的调度逻辑可以用三句话概括:
- 取红黑树最左节点(vruntime 最小的进程)运行
- 进程运行时,vruntime 不断增加(高权重进程增加慢)
- vruntime 增加后,进程从红黑树摘出、更新 vruntime、重新插入
这就是”完全公平”的本质——不是所有进程获得绝对相同的时间,而是 vruntime 趋于平衡。
五、调度周期与时间片:CFS 怎么决定一次跑多久?
CFS 没有固定时间片,但有一个调度周期(sched_latency),默认 6ms(低负载)到 48ms(高负载)。
在一个调度周期内,每个进程都会运行一次。每个进程分到的时间 = 调度周期 × (该进程权重 / 所有进程权重之和)。复制
假设 3 个进程,权重分别为 1024(A)、512(B)、512(C),调度周期 = 6ms:
A 的时间 = 6ms × 1024/2048 = 3ms
B 的时间 = 6ms × 512/2048 = 1.5ms
C 的时间 = 6ms × 512/2048 = 1.5ms1.2.3.4.5.
进程数越多,每个进程分到的时间越短。为了避免时间片太短导致频繁切换,CFS 设置了最小时间片(min_granularity),默认 0.75ms,低于这个值就不切换。
六、Linux 完整调度层次:CFS 不是唯一的
CFS 只是 Linux 调度器的一部分。Linux 的调度器是分层的,不同类型的进程走不同的调度器:
实时进程(SCHED_FIFO/SCHED_RR)只要存在,就会抢占所有普通进程,nice 值对它们没有意义。音视频驱动、工业控制等对延迟敏感的场景会用到实时调度。
普通应用程序几乎都跑在 CFS 下,通过 nice 值控制优先级。
七、实战:如何调整进程优先级?
复制
# 启动时设置 nice 值(-20 最高,+19 最低)
nice -n -5 ./my_program # nice = -5(需要 root)
nice -n 10 ./background_job # nice = +10(普通用户可以调高不能调低)
# 修改正在运行的进程
renice -n 5 -p 1234 # 把 PID 1234 的 nice 值改为 5
# 查看进程的 nice 值和调度策略
ps -o pid,ni,cls,comm -p 1234
# PID NI CLS COMMAND
# 1234 5 TS my_program
# TS = SCHED_OTHER(普通 CFS),RR = 实时轮转,FF = 实时先进先出
# 设置实时优先级(需要 root)
chrt -f 50 ./realtime_task # SCHED_FIFO,优先级 50
chrt -r 50 ./realtime_task # SCHED_RR,优先级 50
# 查看调度策略
chrt -p 12341.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.
在 C 代码里直接设置:复制
#include <sched.h>
// 设置实时调度(需要 CAP_SYS_NICE 权限)
struct sched_param param = { .sched_priority = 50 };
sched_setscheduler(0, SCHED_FIFO, ¶m);
// 普通进程设置 nice 值
nice(10); // 降低优先级1.2.3.4.5.6.7.8.
八、CFS 的边界情况:新进程和睡醒进程怎么处理?
新进程的 vruntime 初始化:
- 如果新进程从 0 开始计 vruntime,而其他进程 vruntime 已经跑到几百毫秒,新进程会一直抢占 CPU,直到 vruntime 赶上来。这不合理。
- 实际上,新进程的 vruntime 初始值 = 当前 CPU 运行队列里最小的 vruntime(min_vruntime)。这样新进程从”起跑线”开始,而不是从 0 开始。
睡眠唤醒的进程:
- 进程睡眠期间不更新 vruntime,醒来后 vruntime 可能远小于其他进程,会一直抢占 CPU。
- CFS 的处理:进程唤醒时,将其 vruntime 设置为 max(其原始 vruntime, min_vruntime – sched_latency)——既保证它能获得一些”补偿”,又不会让它无限制地占用 CPU。
九、高频面试题精析
Q:CFS 的”完全公平”是什么意思?
不是所有进程获得绝对相同的 CPU 时间,而是”理想中的 CPU 使用时间”——每个进程都精确获得按权重分配的 CPU 份额。实现手段是通过 vruntime 使每个进程的”虚拟运行时间”趋于相等。
Q:nice 值和 priority 有什么区别?
priority(PRI)是调度器内部用的实际优先级,包含 nice 值的影响以及动态调整。用户可以通过 nice(-20 到 +19)影响普通进程的优先级,实际 priority = 20 + nice。实时进程有单独的实时优先级(1-99),不通过 nice 控制。
Q:为什么 Redis 建议降低进程优先级?
Redis 通常不建议使用实时优先级,反而建议不调整优先级(用默认 CFS)。因为实时进程如果陷入死循环或长时间运行,会把所有普通进程饿死,系统无响应。Redis 的高性能主要靠单线程+epoll,不依赖实时调度。
Q:Linux 上怎么让一个程序”独占” CPU?
几种方法:① chrt -f 99 设最高实时优先级(危险);② taskset -c 3 ./prog 绑定到 CPU 3,配合 isolcpus=3 内核参数把 CPU 3 从调度器隔离;③ 容器/cgroup 限制 CPU 分配。
十、结语
理解了 CFS,三个核心点牢记:复制
vruntime(虚拟运行时间)—— 公平性的度量标准
红黑树(最左节点) —— O(1) 选出下一个进程
weight(权重) —— 通过 nice 值决定 vruntime 增速1.2.3.
三者组合,就是 Linux 每秒钟在数百个进程之间精确分配 CPU 时间的秘密。
这也解释了为什么服务器上 100 个进程同时跑,没有一个进程会被彻底饿死——CFS 保证了每个进程都能获得至少一点 CPU 时间,同时让高优先级进程获得更多份额。



暂无评论内容