CFS调度器深度解析：完全公平调度器原理

说到Linux调度器，CFS（Completely Fair Scheduler）是我个人最欣赏的一个模块。它从2.6.23版本引入内核，彻底改变了传统调度器的设计思路。说白了，CFS的目标很简单——让每个进程都能公平地获得CPU时间。

你可能会问：什么叫「公平」？嗯，CFS的公平不是让每个进程跑同样长的时间，而是让每个进程获得与其权重成比例的CPU时间。权重高的进程（比如你前台交互的程序）自然能分到更多时间片。

虚拟运行时间（vruntime）

CFS的核心概念就是vruntime。我刚开始研究这个的时候，也觉得有点绕。其实很简单——vruntime记录的是进程实际运行时间，但经过了权重归一化处理。

公式是这样的：

vruntime += 实际运行时间 * (NICE_0_LOAD / 进程权重)

NICE_0_LOAD是个固定值（1024），代表普通优先级进程的权重。权重越高，vruntime增长越慢。这意味着高优先级进程虽然跑得快，但它的「虚拟时间」走得慢，所以能获得更多CPU时间。

我在项目中遇到过一个问题：某个后台批处理任务总是抢不到CPU，导致业务延迟。排查后发现，它的nice值设得太低（权重小），vruntime增长太快，CFS自然就不爱选它。调高nice值后，问题就解决了。

红黑树数据结构

CFS用红黑树来管理所有可运行进程。为什么选红黑树？因为我们需要高效地找到vruntime最小的节点。

红黑树的特点：

• 自平衡二叉搜索树
• 插入、删除、查找的时间复杂度都是O(log n)
• 最左节点就是vruntime最小的进程

CFS把每个可运行进程作为一个节点插入红黑树，键值就是vruntime。调度时，直接取最左节点即可。

红黑树的操作流程：

1. 进程创建时，初始化vruntime并插入红黑树
2. 进程运行时，更新vruntime
3. 进程被抢占或时间片用完，重新插入红黑树
4. 进程退出时，从红黑树删除

调度延迟与最小粒度

调度延迟（sched_latency）和最小粒度（min_granularity）是CFS的两个关键参数。我调优时经常跟它们打交道。

调度延迟：CFS保证所有可运行进程在一个调度延迟内至少被调度一次。默认值是6ms（桌面）或24ms（服务器）。

最小粒度：每个进程至少运行的时间，默认是0.75ms。这是为了防止频繁上下文切换导致的开销。

这两个参数的关系：

时间片 = max(最小粒度, 调度延迟 / 可运行进程数)

举个例子：假设调度延迟是6ms，有4个可运行进程，那么每个进程的时间片就是6/4=1.5ms。如果有100个进程，时间片就是max(0.75, 6/100)=0.75ms。

调优建议：

• 桌面系统：调度延迟设小（4-6ms），响应更快
• 服务器系统：调度延迟设大（12-24ms），吞吐量更高
• 实时任务：考虑使用RT调度类，别用CFS

CFS调度流程

我画了一张流程图，帮你理解CFS的核心逻辑：

这个流程看起来简单，但实际实现中有很多细节。比如进程被唤醒时，vruntime需要做一定的补偿，防止它被饿死。还有组调度场景下，红黑树里存的是调度实体（sched_entity），而不是直接存进程。

实际调优案例

我记得有一次帮客户调优数据库服务器。他们的MySQL实例总是响应慢，但CPU利用率只有30%。

排查后发现：

• 调度延迟是默认的24ms（服务器配置）
• 有8个MySQL线程在竞争CPU
• 每个线程时间片是3ms
• 但MySQL的查询经常在1ms内就能完成，却要等3ms才能被调度

解决方案：把调度延迟从24ms降到12ms，最小粒度从0.75ms降到0.5ms。这样每个线程的时间片变成1.5ms，查询响应时间直接减半。

CFS的设计哲学就是「简单、公平、高效」。它用红黑树和vruntime这两个核心概念，优雅地解决了多任务调度问题。理解这些原理，你就能在遇到调度问题时，快速定位并解决。

嗯，关于CFS的核心内容就这些。记住一点：调度器不是越快越好，而是要在公平性、响应时间和吞吐量之间找到平衡点。