Linux内核进程调度器深度实战：从CFS虚拟运行时到EAS能效调度

Linux内核进程调度器是操作系统的核心组件，负责在多个可运行进程之间分配CPU资源。Linux 2.6.23开始引入的完全公平调度器(CFS)彻底改变了内核调度的思路，而随着硬件复杂度提升，调度器架构已经演变为多策略并存的复合体。本文将从源码级别深入解析Linux内核调度器的架构设计与实战调优。

一、调度策略体系：从实时类到普通类

Linux内核将进程分为两大类别：实时进程（SCHED_FIFO、SCHED_RR、SCHED_DEADLINE）和普通进程（SCHED_NORMAL/SCHED_OTHER、SCHED_BATCH、SCHED_IDLE）。这两类进程在调度时有一个核心原则：实时进程同级优先于普通进程，即SCHED_FIFO/SCHED_RR任务在可运行时优先即时执行。

// include/linux/sched.h
enum sched_policy {
    SCHED_FIFO = 0,    // 先进先出，无时间片，高优先级可占有CPU直到主动让出
    SCHED_RR    = 1,   // 时间片轮转：理论上与FIFO同级，但分配合适时间片
    SCHED_OTHER = 2,   // CFS的普通调度策略，所有用户进程的默认选项
    SCHED_BATCH = 3,   // 批处理：避免同等级进程之间频繁切换，能力有限且计算密集
    SCHED_IDLE   = 5,  // 极低优先级，仅在系统完全闲置时可达最低的用户优先级
    SCHED_DEADLINE = 6 // 时间负载调度，EDF(Earliest Deadline First)算法
};

各策略适用场景：

• SCHED_FIFO：适用于硬实时任务，如信号处理、音视频处理循环，优先级设置后不被剥夺
• SCHED_RR：适用于软实时但需多任务公平共享的场景，高优先级RR任务轮流执行
• SCHED_DEADLINE：最精确的实时策略，基于截止时间调度，保证最坏情况延迟
• SCHED_BATCH：适用于编译、批量渲染等后台任务，不干扰交互式应用
• SCHED_IDLE：适用于几乎不需要CPU的极低频任务

二、CFS核心原理：完全公平调度器深度剖析

2.1 虚拟运行时（vruntime）机制

CFS的核心创新是放弃传统的时间片概念，转而使用虚拟运行时（virtual runtime）作为调度决策的衡量指标。vruntime记录了一个进程经过优先级加权后的实际运行时间，nice值越低的进程vruntime增长越慢，从而获得更多CPU份额。

// 核心公式：vruntime = 实际运行时间 × 优先级权重
// 即：vruntime_delta = (delta_exec × NICE_0_LOAD) / se.load.weight

// kernel/sched/fair.c - update_curr()
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;  // 实际执行时间
    curr->vruntime += calc_delta_fair(delta_exec, curr);  // 加权后累加到vruntime
    curr->exec_start = now;
}

其中的 calc_delta_fair 实现了权重归一化：

static inline u64 calc_delta_fair(u64 delta, struct sched_entity *se)
{
    if (unlikely(se->load.weight != NICE_0_LOAD))
        delta = __calc_delta(delta, NICE_0_LOAD, &se->load);
    return delta;
}

权重与nice值的映射关系：prio_to_weight数组定义了nice值到权重的映射，nice相差1级对应约10%的CPU份额差异（1024/1293 ≈ 0.9）。

// kernel/sched/core.c
const int sched_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,
};

2.2 红黑树调度队列

CFS使用红黑树（rbtree）作为调度队列，以vruntime作为键值。每颗红黑树的最左侧节点即vruntime最小的进程，是下一个被调度的候选。这一设计使得查找最快进程的时间复杂度仅为O(log N)。

// kernel/sched/fair.c - pick_next_entity()
static struct sched_entity *__pick_first_entity(struct cfs_rq *cfs_rq)
{
    struct rb_node *left = cfs_rq->rb_leftmost;
    return rb_entry(left, struct sched_entity, run_node);
}

// 入队操作
static void __enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
    struct rb_node **link = &cfs_rq->tasks_timeline.rb_node;
    struct rb_node *parent = NULL;
    struct sched_entity *entry;
    // ... 按vruntime插入排序
    rb_link_node(&se->run_node, parent, link);
    rb_insert_color(&se->run_node, &cfs_rq->tasks_timeline);
}

// 出队操作
static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
    rb_erase(&se->run_node, &cfs_rq->tasks_timeline);
}

CFS调度类的核心操作(sched_class)是内核的可扩展接口，定义了enqueue_task、dequeue_task、pick_next_task等钩子函数，fair_sched_class实现了CFS的逻辑：

const struct sched_class fair_sched_class = {
    .next          = &idle_sched_class,
    .enqueue_task  = enqueue_task_fair,
    .dequeue_task  = dequeue_task_fair,
    .pick_next_task = pick_next_task_fair,
    .task_tick     = task_tick_fair,
};

2.3 CFS带宽控制（Bandwidth Control）

Linux 3.2引入了CFS带宽控制，通过cpu.cfs_quota_us和cpu.cfs_period_us两个参数，实现了对普通进程组的CPU使用硬限制。当组内所有进程在period时间内累计使用量达到quota即被throttled。

三、SCHED_DEADLINE：截止时间调度策略

SCHED_DEEDLINE是Linux 3.14引入的实时调度策略，基于EDF（Earliest Deadline First）算法。每个任务声明三个参数：

• Runtime (Q)：每个周期内需要的最大CPU时间
• Period (P)：任务执行周期
• Deadline (D)：默认等于Period，即隐式截止时间模型

通过sched_setattr系统调用设置：

struct sched_attr {
    __u32 size;
    __u32 sched_policy;      // SCHED_DEADLINE
    __u64 sched_flags;
    __s32 sched_nice;
    __u32 sched_priority;    // 对DL无效
    __u64 sched_runtime;     // 纳秒
    __u64 sched_deadline;    // 纳秒
    __u64 sched_period;      // 纳秒
};

// 使用示例
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_setattr(0, &attr, 0);

SCHED_DEADLINE的准入测试(admission control)使用全局EDF的可调度性检验：所有DL任务的(Σ{Ci/Ti})必须不超过CPU核心数N（在单核场景下即为不超过1.0或100%）。内核通过维护运行总和的跟踪来确保不超过此限制。

四、cgroup CPU子系统深度实践

4.1 CFS带宽控制实战

通过cgroup v1的cpu子系统和v2的cpu控制器，可以精细化控制进程组的CPU分配：

# 创建cgroup并设置CPU限制（cgroup v1）
mkdir -p /sys/fs/cgroup/cpu/mygroup
echo 50000 > /sys/fs/cgroup/cpu/mygroup/cpu.cfs_period_us   # 周期100ms
echo 25000 > /sys/fs/cgroup/cpu/mygroup/cpu.cfs_quota_us    # 每周期最多用25ms
echo $PID > /sys/fs/cgroup/cpu/mygroup/cgroup.procs

# cgroup v2等价操作
mkdir -p /sys/fs/cgroup/mygroup
echo "25000 100000" > /sys/fs/cgroup/mygroup/cpu.max        # 25ms/100ms
echo $PID > /sys/fs/cgroup/mygroup/cgroup.procs

# 使用systemd-run创建受限服务
systemd-run --scope -p CPUQuota=25% --unit=myapp.service /path/to/app

4.2 cpuset与NUMA感知

通过cpuset子系统实现CPU绑核和NUMA亲和性，减少跨NUMA节点内存访问延迟：

# 创建专用CPU组（cgroup v2）
mkdir -p /sys/fs/cgroup/isolated
echo "4-7" > /sys/fs/cgroup/isolated/cpuset.cpus        # 使用核心4-7
echo "1" > /sys/fs/cgroup/isolated/cpuset.mems          # 使用NUMA节点1
echo $PID > /sys/fs/cgroup/isolated/cgroup.procs

# isolcpus内核参数（启动时隔离核心，不参与默认调度）
# GRUB配置: GRUB_CMDLINE_LINUX="isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7"

五、调度延迟调优与性能分析

5.1 关键调优参数

5.2 交互式应用调优

对于桌面和交互式应用，降低sched_wakeup_granularity_ns到2ms以内可以更快抢占，配合sched_min_granularity_ns约1ms使用。但此设置会增加上下文切换次数，计算密集型负载需谨慎。

# 桌面交互式调优示例
sysctl -q kernel.sched_min_granularity_ns=1000000
sysctl -q kernel.sched_wakeup_granularity_ns=1500000
sysctl -q kernel.sched_migration_cost_ns=250000

# HPC/批处理调优示例
sysctl -q kernel.sched_min_granularity_ns=10000000
sysctl -q kernel.sched_wakeup_granularity_ns=15000000

5.3 使用perf sched分析调度延迟

# 记录调度事件30秒
perf sched record -- sleep 30

# 分析调度延迟分布
perf sched latency --sort max

# 可视化时间线
perf sched map

# 统计每个进程的调度延迟
# Example output: 
#  Task                  |   Runtime ms  | Switches | Average delay ms | Maximum delay ms |
# ---------------------------------------------------------------------------------------
#  kworker/0:1          |      1.969    |   100    |        0.045     |        3.568     |
#  myapp-main            |   2356.214    |    42    |        0.112     |        5.213     |

5.4 schedstat与/proc分析

# 查看进程调度统计（内核配置CONFIG_SCHEDSTATS=y）
cat /proc/$PID/schedstat
# 格式：运行时长(纳秒) 等待时长(纳秒) 时间片次数

# 查看CFS组总计
cat /sys/fs/cgroup/cpu/machine.slice/cpu.stat
# nr_periods 12345           # 超出quota被周期数
# nr_throttled 345          # 实际被throttled次数
# throttled_time 123456789  # 总等待时间(ns)

六、EAS能耗感知调度器

6.1 EAS基本原理

EAS（Energy Aware Scheduling）是ARM big.LITTLE架构催生的调度优化，在Linux 5.x后逐步成熟。传统负载均衡只追求性能，而EAS在功耗模型（Energy Model）中为每颗CPU定义性能-功耗曲线，主动选择能效比最优的CPU运行任务。

EAS通过容量（capacity）来量化CPU性能，ARM平台上通过capacity-dmips-mhz属性描述每颗核心的相对算力，例如大核cap=1024、小核cap=411。调度器在选核时优先选择接近任务利用率且功耗更低的CPU。

// 核心数据结构：每颗CPU的性能域（Performance Domain）
// kernel/sched/cpufreq_schedutil.c - 与cpufreq联动
// sd = sched_domain - 层级化调度域

struct perf_domain {
    struct cpumask *cpus;     // 该域覆盖的CPU集合
    struct em_perf_domain *em;// 能耗模型
};

// 目标：在满足负载需求的前提下，找到使功耗增量ΔP最小的CPU

// kernel/sched/fair.c - find_energy_efficient_cpu()
static int find_energy_efficient_cpu(struct task_struct *p, struct rq *prev)
{
    unsigned long prev_util, best_util = ULONG_MAX;
    struct perf_domain *pd;
    int cpu, best_cpu = -1;
    rcu_read_lock();
    pd = rcu_dereference(this_cpu_pd);
    // 遍历性能域计算能量成本
    // 最终选择使 energy = power(prev) - power(prev) 最小的CPU
    rcu_read_unlock();
    return best_cpu;
}

# 检查系统是否启用EAS
cat /proc/sys/kernel/sched_energy_aware
# 1=EAS启用（典型于移动/嵌入式场景），0=使用传统schedutil

# 查看CPU频率调节器
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# schedutil 是EAS的最佳搭档
# 设置所有CPU使用schedutil
for cpu in /sys/devices/system/cpu/cpu*/cpufreq; do
    echo schedutil > $cpu/scaling_governor
done

# 查看能耗模型（debugfs）
cat /sys/kernel/debug/energy_model/pd0/cost_i  # 功率表
cat /sys/kernel/debug/energy_model/pd0/cpu*/capacity  # 容量表

# kubelet配置片段
cpuManagerPolicy: static
kubeReserved:
  cpu: 500m
systemReserved:
  cpu: 500m

# Guaranteed Pod示例（CPU limits等于requests）
apiVersion: v1
kind: Pod
metadata:
  name: high-perf
spec:
  containers:
  - name: main
    resources:
      requests:
        cpu: "4"
      limits:
        cpu: "4"   # 将分配4个独占物理核心

# Docker限制CPU份额（份额非硬限制）
docker run --cpus=1.5 myimage  # 等效于cfs_quota=150000, period=100000

# 绑核运行
docker run --cpuset-cpus="2,3" --cpus=2 myimage

# Podman同理
podman run --cpus=1.5 --cpuset-cpus=2-3 myimage

# 使用chrt临时设置实时策略
chrt -f 99 ./realtime_app  # SCHED_FIFO优先级99
chrt -r 50 ./soft_realtime  # SCHED_RR优先级50
chrt -d --runtime 10000000 --deadline 20000000 --period 20000000 0 ./dl_app

#!/bin/bash
echo "=== CPU调度器概览 ==="
echo "活动调度策略统计（实时类：FIFO/RR/DL，普通类：CFS等)"
ps -eo pid,class,rtprio,ni,comm | awk '
  $2=="FF"||$2=="RR"||$2=="DL" {rt++}
  $4<0 {nice_low++}
  END{print "实时进程:",rt," nice<0:",nice_low}'

echo -e "\n=== CFS带宽组状态 ==="
for grp in /sys/fs/cgroup/cpu/*/cpu.stat; do
  [ -f "$grp" ] || continue
  dir=$(dirname $grp)
  nr_periods=$(grep nr_periods $grp | awk '{print $2}')
  if [ "$nr_periods" -gt 0 ] 2>/dev/null; then
    echo "[$dir] $(cat $grp)"
  fi
done

echo -e "\n=== 当前调度参数 ==="
sysctl kernel.sched_{min_granularity_ns,wakeup_granularity_ns,migration_cost_ns}

echo -e "\n=== EAS状态 ==="
cat /proc/sys/kernel/sched_energy_aware 2>/dev/null || echo "未启用"