Linux CFS调度器：时间片与vruntime计算原理-代码聚汇网

Linux CFS调度器：时间片与vruntime计算原理

东予薏米·2026-08-16·阅读 22 GEO检测（免费）

Linux内核CFS调度器进程调度

|难度：普通|阅读约 14 分钟

1. CFS调度器与进程入队机制概述

在Linux内核的进程管理模块中，完全公平调度器（Completely Fair Scheduler，CFS）负责以公平高效的方式分配CPU时间给各个运行中的进程。当一个新的进程变为可运行状态时，内核会调用enqueue操作将其加入CFS运行队列，这个过程中最关键的两个计算就是时间片（time slice）和虚拟运行时间（vruntime）的确定。

我曾在处理一个服务器负载均衡问题时，发现某个高优先级进程长期占用CPU导致其他任务饥饿。通过分析CFS的enqueue机制才明白，问题的根源在于vruntime计算没有考虑权重因子。这个经历让我深刻认识到理解这些底层机制的重要性。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 时间片计算的内部逻辑

2.1 时间片的基本概念

时间片是指一个进程在被调度出去之前允许连续运行的时间长度。在CFS中，时间片并非固定值，而是根据进程的优先级动态计算得出。与传统的O(1)调度器不同，CFS的时间片计算更加精细化。

内核中计算时间片的核心函数是sched_slice()，其基本公式为：

code复制time_slice = (调度周期 * 进程权重) / 总运行队列权重

这里的调度周期（sched_latency）是一个可调参数，默认值为6ms（对应CONFIG_HZ=250）或24ms（CONFIG_HZ=1000）。但在实际运行中，当可运行进程超过sched_nr_latency（通常为8）时，调度周期会按比例放大。

2.2 权重因子的影响

Linux使用优先级到权重的映射表（prio_to_weight）来体现nice值的影响。一个进程的nice值每降低1（优先级提高），获得的CPU时间增加约10%。具体权重值定义在kernel/sched/core.c中：

c复制static const int prio_to_weight[40] = {
 /* -20 */ 88761, 71755, 56483, 46273, 36291,
 /* -15 */ 29154, 23254, 18705, 14949, 11916,
 /* -10 */ 9548, 7620, 6100, 4904, 3906,
 /*  -5 */ 3121, 2501, 1991, 1586, 1277,
 /*   0 */ 1024, 820, 655, 526, 423,
 /*   5 */ 335, 272, 215, 172, 137,
 /*  10 */ 110, 87, 70, 56, 45,
 /*  15 */ 36, 29, 23, 18, 15,
};

我曾遇到过一个案例：将某个关键进程的nice值从0改为-5后，其获得的CPU时间从1024/(1024+1024)=50%提升到了3121/(3121+1024)≈75%，效果立竿见影。

2.3 新进程的特殊处理

对于新创建的进程，CFS会给予一定的"新手福利"。在place_entity()函数中，新进程的vruntime会被初始化为：

c复制vruntime = min_vruntime - (sched_vslice(cfs_rq)/2)

这种设计避免了新进程因为初始vruntime值过大而长时间得不到调度的问题。但在高负载系统中，这个机制可能导致已存在进程的响应时间变长，需要特别注意。

3. vruntime的计算原理

3.1 虚拟运行时间的概念

vruntime是CFS实现公平调度的核心概念，它表示一个进程在"理想公平CPU"上应该已经运行的时间。每次时钟中断时，当前运行进程的vruntime按以下公式更新：

code复制vruntime += 实际运行时间 * NICE_0_LOAD / 当前进程权重

其中NICE_0_LOAD是nice值为0的进程的权重（1024）。这个公式确保了高权重进程的vruntime增长较慢，从而能获得更多CPU时间。

3.2 enqueue时的vruntime初始化

当进程首次加入运行队列时，其vruntime需要合理初始化以避免不公平。内核主要考虑以下因素：

如果进程是新建的（p->se.sum_exec_runtime == 0），采用前文提到的"新手福利"策略
如果是被唤醒的睡眠进程，则保留原有vruntime
对于从其他CPU迁移来的进程，需要根据目标CPU的min_vruntime进行调整

在__enqueue_entity()函数中，关键的调整代码如下：

c复制if (!initial)
    vruntime += cfs_rq->min_vruntime;
else
    vruntime = max_vruntime(se->vruntime, vruntime);

3.3 vruntime的溢出保护

由于vruntime是单调递增的64位变量（u64），理论上不会溢出。但在长期运行的系统中，min_vruntime可能变得非常大，导致新进程的vruntime初始值异常。CFS通过定期调整所有进程的vruntime来避免这个问题：

c复制if (unlikely(cfs_rq->min_vruntime > (1ULL << 40))) {
    u64 offset = cfs_rq->min_vruntime - (1ULL << 30);
    for_each_sched_entity(se)
        se->vruntime -= offset;
}

4. 实际案例：数据库服务的调度优化

4.1 问题现象

某MySQL数据库服务在高峰期出现查询延迟波动，分析发现是CFS调度导致的关键进程响应不及时。具体表现为：

大量短时查询进程频繁创建/退出
关键的后台持久化进程经常被抢占
CPU使用率显示存在明显的调度开销

4.2 解决方案探索

我们尝试了多种调整方案：

调整nice值：将持久化进程设为-5，查询进程保持0
- 效果：持久化进程延迟降低30%，但查询尾延迟增加
修改调度周期：将sched_latency_ns从24ms降为12ms
- 效果：整体响应更及时，但上下文切换开销增加15%
使用cgroup进行隔离：为关键进程创建独立调度组
- 效果最佳，基本消除干扰，但需要额外管理开销

4.3 内核参数调优

最终采用的/proc/sys/kernel参数调整：

bash复制# 减少调度最小粒度，允许更频繁的抢占
echo 3000000 > /proc/sys/kernel/sched_min_granularity_ns

# 增加迁移开销阈值，减少不必要的进程迁移 
echo 500000 > /proc/sys/kernel/sched_migration_cost_ns

# 启用唤醒抢占
echo 1 > /proc/sys/kernel/sched_wakeup_granularity_ns

配合cgroup的cpu子系统设置权重，最终使99%的查询延迟控制在50ms以内。

5. 调试与性能分析技巧

5.1 ftrace跟踪enqueue操作

使用ftrace可以详细观察进程入队过程：

bash复制echo 1 > /sys/kernel/debug/tracing/events/sched/sched_enqueue/enable
cat /sys/kernel/debug/tracing/trace_pipe

典型输出示例：

code复制kworker/1:1-100 [001] d..2. 12345.678901: sched_enqueue: comm=kworker/1:1 pid=100 prio=120 target_cpu=001 vruntime=123456789

5.2 /proc//sched分析

通过proc文件系统可以查看进程的调度信息：

bash复制cat /proc/1234/sched

关键字段说明：

se.vruntime：当前虚拟运行时间
se.sum_exec_runtime：实际运行总时间
se.statistics.wait_start：最后一次入队时间戳

5.3 性能计数器监控

使用perf统计调度相关事件：

bash复制perf stat -e sched:sched_process_exec,sched:sched_process_fork,sched:sched_process_free -a sleep 10

对于enqueue操作，可以重点关注：

sched:sched_enq_task
sched:sched_wakeup

6. 常见问题与解决方案

6.1 新进程饥饿问题

现象：系统长时间运行后，新启动的进程需要很长时间才能获得CPU时间。

原因：min_vruntime增长过大，导致新进程的初始vruntime远大于运行队列中的其他进程。

解决方案：

定期重启关键服务
修改内核参数sched_child_runs_first
使用cgroup限制单个服务的运行时间

6.2 vruntime跳跃问题

现象：进程的vruntime突然大幅增加或减少。

可能原因：

进程在不同CPU间迁移，而各CPU的min_vruntime不一致
内核bug导致计算错误

诊断方法：

开启sched_move_task跟踪点
检查/proc/sched_debug中的CPU差异

6.3 时间片计算不准确

现象：进程实际运行时间与预期时间片严重不符。

排查步骤：

确认进程优先级设置是否正确
检查运行队列权重总和是否异常
验证调度周期参数是否被修改

7. 高级话题：CFS与实时进程的交互

虽然本文主要讨论普通进程的调度，但理解CFS与实时进程（RT）的交互也很重要。当系统中有RT进程时：

CFS运行队列的权重计算会排除RT进程
RT进程总是优先于CFS进程运行
RT进程的运行时间不计入CFS的vruntime

可以通过sched_rt_period_us和sched_rt_runtime_us参数控制RT进程的最大占用比例：

bash复制# 限制RT进程每1秒周期内最多运行0.95秒
echo 1000000 > /proc/sys/kernel/sched_rt_period_us
echo 950000 > /proc/sys/kernel/sched_rt_runtime_us

在实际生产环境中，合理设置这些参数可以防止RT进程完全饿死CFS进程。