Linux内核进程调度与CFS完全公平调度器深度实战——从vruntime红黑树到SCHED_DEADLINE与cgroup v2带宽控制

一、为什么需要深入理解CFS？

作为Linux内核最核心的子系统之一，进程调度器直接影响着系统的吞吐量、响应速度和资源利用率。从早期O(n)调度器到O(1)调度器，再到2.6.23版本引入的完全公平调度器（CFS, Completely Fair Scheduler），Linux的调度哲学经历了从"复杂启发式"到"简洁数学模型"的范式转变。

理解CFS不仅有助于我们排查性能抖动、CPU飙高、负载不均衡等生产问题，更是掌握容器资源隔离、NUMA调优、实时任务保障的基础。本文将深入CFS的数学原理、内核实现、调度策略族、组调度机制、NUMA感知，并结合大量实战案例和调优参数，帮助你彻底吃透Linux进程调度。

二、CFS核心概念与数学模型

2.1 虚拟运行时间（vruntime）

CFS的核心思想极其简洁：让每个可调度实体（sched_entity）的虚拟运行时间尽可能相等。当一个进程运行时，它的vruntime增长；vruntime最小的进程最先被选中执行。

vruntime的计算公式：

vruntime += (delta_exec * NICE_0_LOAD) / se.load

其中 NICE_0_LOAD = 1024（nice 0的权重），delta_exec 是实际运行时间，se.load 是该调度实体的权重。这意味着：

• 高优先级进程（nice值低，权重大）的vruntime增长慢 → 获得更多CPU时间
• 低优先级进程（nice值高，权重小）的vruntime增长快 → 获得更少CPU时间
• nice值每差1级，CPU时间比例约为1.25倍（1024/820 ≈ 1.25）

2.2 红黑树与最左节点

CFS使用红黑树（rbtree）来组织所有可调度实体，键值为vruntime。红黑树的最左节点（leftmost） 始终是vruntime最小的进程，即下一个被调度的目标。

// kernel/sched/fair.c
struct task_struct *pick_next_task_fair(struct rq *rq)
{
    struct sched_entity *se = pick_next_entity(cfs_rq);
    // ...
}

红黑树操作时间复杂度为O(log n)，插入/删除效率极高，即使数万进程也不在话下。

2.3 最小粒度与抢占

当当前进程的vruntime超过红黑树中最小vruntime一个最小粒度（sched_min_granularity）时，内核会设置need_resched标志，在下一个抢占点触发调度：

// 默认sched_min_granularity = 6ms（单核）;// 多核时会按比例放大// sched_wakeup_granularity = 8ms// 唤醒抢占：新进程vruntime < 当前进程vruntime - wakeup_granularity 时抢占

三、CFS调度器内核实现剖析

3.1 核心数据结构

CFS的核心数据结构呈层次化关系：

3.2 调度路径：从时钟中断到进程切换

完整的调度路径如下：

1. 时钟中断 → scheduler_tick()     ↓2. update_curr()         // 计算delta_exec，更新vruntime     ↓3. check_preempt_curr() // 检查是否需要抢占     ↓4. 若需抢占 → sets TIF_NEED_RESCHED     ↓5. 中断返回/系统调用返回 → schedule()     ↓6. pick_next_task()      // 按优先级：stop→dl→rt→fair→idle
     ↓
7. context_switch()        // 切换地址空间和寄存器

3.3 入队与出队：enqueue_entity / dequeue_entity

当进程状态变为可运行（TASK_RUNNING）时，调用enqueue_entity()将其插入红黑树；当进程睡眠或被抢占时，调用dequeue_entity()将其移除：

static void enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
{
    // 更新负载统计
    update_load_avg(cfs_rq, se, UPDATE_TG);
    // 加入红黑树
    __enqueue_entity(cfs_rq, se);
    // 计算h_nr_running以支持组调度
    cfs_rq->h_nr_running++;
    se->on_rq = 1;
}

3.4 update_curr：vruntime的实时计算

update_curr()是CFS的灵魂函数，在每次scheduler_tick()和上下文切换时被调用：

static void update_curr(struct cfs_rq *cfs_rq){
    struct sched_entity *curr = cfs_rq->curr;    u64 now = rq_clock_task(rq_of(cfs_rq));    u64 delta_exec;
    
    delta_exec = now - curr->exec_start;  // 实际执行时间    if (unlikely(!delta_exec)) return;
        curr->exec_start = now;           // 重置开始时间
    curr->sum_exec_runtime += delta_exec;
        // 核心：vruntime = 实际时间 * NICE_0_LOAD / 权重
    curr->vruntime += calc_delta_fair(delta_exec, curr);    update_min_vruntime(cfs_rq);           // 更新cfs_rq->min_vruntime}

四、调度策略与优先级体系

4.1 SCHED_NORMAL（SCHED_OTHER）：标准CFS

默认调度策略，适用于绝大多数普通进程。nice值范围-20~19，对应优先级权重1024~15：

4.2 SCHED_BATCH

针对批处理任务优化的策略。与SCHED_NORMAL关系如下：

• 同样使用vruntime，但降低唤醒抢占倾向
• 新唤醒的进程不会立即抢占运行中的进程
• 减少上下文切换开销，提高吞吐量
• 适合make -j、视频转码等计算密集型批量任务

4.3 SCHED_IDLE

极低优先级策略。SCHED_IDLE进程仅在CPU空闲时才被调度，其权重极低（WEIGHT_IDLE_PRIO = 3，约为NICE_0_LOAD的0.3%），几乎不会干扰正常任务。适合后台统计、日志收集等可延迟任务。

4.4 实时调度器：SCHED_FIFO 与 SCHED_RR

虽然本文聚焦CFS，但实时策略与CFS密切相关：

• SCHED_FIFO：无时间片概念，高优先级RT任务一直运行直到阻塞或主动让出
• SCHED_RR：带时间片的FIFO，同类优先级任务轮转
• RT优先级1~99，数值越大优先级越高

重要守护参数：

kernel.sched_rt_runtime_us = 950000  # 每周期RT最多占用95%CPU
kernel.sched_rt_period_us  = 1000000 # 周期为1秒

为何保留5%给普通任务？防止RT任务失控时导致系统完全卡死（如init进程饥饿）。

4.5 SCHED_DEADLINE：EDF + CBS

从3.14版本引入的EDF（Earliest Deadline First）调度器，使用CBS（Constant Bandwidth Server）算法：

# 使用SCHED_DEADLINE的sched_setattr系统调用struct sched_attr attr = {
    .size = sizeof(attr),
    .sched_policy = SCHED_DEADLINE,
    .sched_runtime  = 10 * 1000 * 1000,   // 10ms 运行时间
    .sched_deadline = 20 * 1000 * 1000,   // 20ms 截止时间
    .sched_period   = 20 * 1000 * 1000,   // 20ms 周期
};

SCHED_DEADLINE保证了每个周期内进程至少能获得runtime的CPU时间，在deadline前完成最关键的工作，是RT音视频处理、工业控制的首选。

五、组调度与cgroup v2 CPU带宽控制

5.1 CFS组调度原理

传统的CFS无法区分用户/容器级别的资源分配。内核引入组调度（Group Scheduling） 后，每个cgroup拥有自己的cfs_rq，进程的vruntime在组内公平分配，而组之间由父级CPU cfs_rq再次分配。

这意味着进程的调度实体是一个双层结构：

group A: 10个进程 → 每个进程获得 ~50% CPU
group B: 2个进程  → 每个进程获得 ~50% CPU
（假设A和B权重相同）

5.2 cgroup v1：cpu.cfs_quota_us / cpu.cfs_period_us

通过cpu控制组限制带宽：

# 创建一个cgroup，限制最多使用0.5个CPU
mkdir /sys/fs/cgroup/cpu/mycontainer
echo 50000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_period_usecho 50000 > /sys/fs/cgroup/cpu/mycontainer/cpu.cfs_quota_us  # 50000/100000 = 0.5 CPU

注意：cfs_quota_us可以超过cfs_period_us，表示在多核上的总带宽。例如：

echo 800000 > cpu.cfs_quota_us  # 可同时使用8个核心
echo 100000 > cpu.cfs_period_us

5.3 cgroup v2 cpu.weight

cgroup v2用更直观的权重替代了quota/period：

# 权重范围1~10000，默认100echo 200 > /sys/fs/cgroup/mycontainer/cpu.weight  # 双倍权重
echo 50  > /sys/fs/cgroup/mycontainer/cpu.weight  # 半倍权重

# 同时支持带宽上限echo "max 200000 100000" > /sys/fs/cgroup/mycontainer/cpu.max
# 表示每100ms最多用200ms CPU时间（即2核上限）

5.4 cgroup v2与实时带宽（rt）

cgroup v2对RT任务也提供了带宽控制：

# 限制RT带宽为0.05秒/秒
echo "max 50000000 1000000000" > /sys/fs/cgroup/mycontainer/cpu.rt.max

六、NUMA感知调度

6.1 NUMA架构下的调度挑战

在NUMA系统中，本地内存访问延迟约100ns，跨节点访问可能达到300ns以上。如果调度器将进程调度到远端节点，性能将显著下降。

Linux内核通过NUMA Balancing和AutoNUMA两个机制来缓解这个问题：

• AutoNUMA：周期性扫描进程的页访问统计，选择访问最频繁的节点作为home node
• sched_numa_balancing：在任务唤醒/创建时选择更合适的节点

6.2 关键参数

kernel.numa_balancing = 1              # 开启自动NUMA平衡kernel.numa_balancing_scan_delay_ms = 1000  # 新任务1秒后开始扫描kernel.numa_balancing_scan_period_min_ms = 200
kernel.numa_balancing_scan_period_max_ms = 60000
vm.zone_reclaim_mode = 0               # 不要在直接回收时杀死进程（生产建议关闭）

6.3 NUMA与CFS的协同

每一个NUMA节点都有独立的rq/cfs_rq结构。CFS在选择目标CPU时，会综合考虑：

1. 当前CPU（如果仍处于空闲）
2. Sibling SMT核心（共享L1/L2缓存）
3. 同NUMA节点的其他核心
4. 远端NUMA节点（优先级最低）

我们可以通过numactl和taskset控制进程的CPU亲和性：

numactl --cpunodebind=0 --membind=0 ./applicationtaskset -c 0-7 ./pinned_task    # 绑定到CPU 0-7

# 查看负载和进程状态uptime               # 负载>CPU核心数说明存在排队
vmstat 1            # 观察cs列（上下文切换）和r列（运行队列长度）
pidstat -w 1        # 自愿/非自愿上下文切换

# 高切换 + CPU利用率低 = 进程数太多或锁争用
# 高切换 + CPU利用率高 = 真正计算密集

# 检查调度延迟cat /proc/<PID>/sched    # 查看se.statistics.wait_sum（等待总时间）
perf sched record -a sleep 10
perf sched latency          # 查看最大调度延迟perf sched map                 # 可视化调度分布

kernel.sched_min_granularity_ns = 10000000   # 10ms
kernel.sched_wakeup_granularity_ns = 15000000 # 15ms
kernel.sched_migration_cost_ns = 5000000      # 5ms

kernel.sched_min_granularity_ns = 20000000   # 20ms
kernel.sched_wakeup_granularity_ns = 22000000 # 22ms
kernel.sched_migration_cost_ns = 500000000    # 500ms

# /etc/sysctl.conf
vm.overcommit_memory = 1kernel.sched_autogroup_enabled = 0  # 在容器中通常希望关闭autogroup

# nice值调整nice -n -10 ./priority_app     # 启动时设置renice -n -5 -p $(pgrep app)   # 运行时调整# chrt设置实时优先级chrt -f 50 ./rt_task            # SCHED_FIFO 优先级50
chrt -r 30 ./rt_task            # SCHED_RR 优先级30chrt -d --sched-runtime 10000000 --sched-deadline 20000000 \   --sched-period 20000000 ./deadline_task

# cgroup CPU使用率监控
cat /sys/fs/cgroup/cpu/cpu.stat        # idle,system,user,nr_periods,throttled_time
systemd-cgtop                          # 实时查看各cgroup的CPU使用# BPF/bcc工具trace 'sched_switch'             # 跟踪上下文切换
funclatency pick_next_task_fair        # 测量pick_next_task延迟
runqlat                                # 测量运行队列延迟分布

# 单个进程的调度统计$ cat /proc/self/schedmy_app (12345, #threads: 1)
-------------------------------------------------------------------
se.exec_start                                :       53286503.320000
se.vruntime                                  :           412.340172
se.sum_exec_runtime                          :           123.456789
se.load.weight                               :          1024
se.avg.load_sum                              :            12000
se.avg.runnable_load_sum                     :            10000
se.avg.util_sum                              :             8192
se.nr_migrations                             :               12
se.statistics.wait_start                     :             0.000000
se.statistics.sleep_start                    :             0.000000
se.statistics.block_start                    :             0.000000
se.statistics.sleep_max                      :         123.456789se.statistics.wait_max                      :          12.345678  # 关键：最大等待时间！
se.statistics.wait_sum                       :         2345.678901
se.statistics.wait_count                     :            2345se.statistics.iowait_sum                     :          567.890123
se.statistics.iowait_count                   :             432policy                                     :                    0  # SCHED_NORMAL
nice                                        :                    0utime                                      :         123456789

// 频率：每个tick（1ms）调用一次update_load_avg()load_avg = load_avg * y + load * (1 - y)   // y = 0.9785（约32ms衰减至1/2）

# 1. 查看等待时间是否异常
for pid in $(pgrep postgres); do
    grep "wait_max" /proc/$pid/sched
done
# 结果：某些进程wait_max超过100ms！# 2. 查看CPU调度情况perf sched record -a sleep 30
perf sched latency | head -20# 发现大量调度延迟来自watchdog和kworker抢占# 3. 检查内核参数cat /proc/sys/kernel/sched_min_granularity_ns   # 6000000 (6ms)
cat /proc/sys/kernel/sched_rt_runtime_us             # 950000 (95%)

# 4. 最终定位：周期性RT任务（watchdog）抢占PostgreSQL

# 方案1：降低RT带宽预留echo 900000 > /proc/sys/kernel/sched_rt_runtime_us  # 90%

# 方案2：隔离CPU核心# kernel cmdline: isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7taskset -c 4-7 postgres -D /var/lib/postgresql/data# 方案3：设置postgres为高优先级但不使用RTnice -n -20 -p $(pgrep postgres | head -1)