Linux 内核调度器深度实战：从 CFS 完全公平调度到 EEVDF 的演进与性能调优
引言
CPU 调度器是操作系统内核最核心的组件之一，它直接决定了系统的吞吐量、响应时间和资源利用率。Linux 内核调度器经历了从 O(n) 调度器、O(1) 调度器，到 CFS（Completely Fair Scheduler），再到 2023 年 Linux 6.6 引入的 EEVDF（Earliest Eligible Virtual Deadline First）的持续演进。
本文将深入剖析 Linux 内核调度器的设计哲学、核心数据结构、算法实现，以及在生产环境中的性能调优实战。我们将从 scheduler 的本质问题出发，逐步深入到 CFS 的红黑树机制、vruntime 计算、NUMA 负载均衡，以及 EEVDF 如何解决 CFS 的延迟抖动问题。
第一章：调度器基础——问题建模与设计约束
1.1 什么是调度
操作系统的 CPU 调度本质上是一个 资源分配问题：给定 N 个可运行任务（runnable tasks）和 M 个 CPU 核心（M < N），在每个时刻决定哪个任务在哪个 CPU 上执行。这个看似简单的决策背后，需要同时满足多个相互冲突的目标：
- 公平性（Fairness）：每个任务应获得与其权重成比例的 CPU 时间
- 低延迟（Low Latency）：交互式任务的响应时间应尽可能短
- 高吞吐（Throughput）：批处理任务应在合理时间内完成
- 亲和性（Affinity）：尽量利用缓存热度，减少 CPU 迁移开销
- 能效（Power Efficiency）：在移动设备上尽量集中任务到大核，让空闲核休眠
1.2 Linux 调度器架构概览
Linux 内核采用 模块化调度类（sched_class） 架构，通过优先级链表管理多个调度器类：
stop_sched_class // 最高优先级，用于 CPU 热插拔、IPI
dl_sched_class // Deadline 调度类，SCHED_DEADLINE
rt_sched_class // 实时调度类，SCHED_FIFO / SCHED_RR
fair_sched_class // 完全公平调度类（CFS / EEVDF），SCHED_NORMAL/SCHED_BATCH/SCHED_IDLE
idle_sched_class // 空闲调度类，仅在没有任务可运行时执行
当需要选择下一个任务运行时，内核按此优先级依次遍历每个 sched_class 的 pick_next_task 方法，第一个返回非 NULL 的任务胜出。这种设计确保了实时任务绝对优先于普通任务，Deadline 又高于 FIFO/RR。
1.3 任务状态与上下文切换
Linux 中的任务（task_struct）有以下与调度相关的关键状态：
- TASK_RUNNING：要么正在 CPU 上执行，要么在运行队列中等待调度
- TASK_INTERRUPTIBLE：睡眠等待某个条件，可被信号中断
- TASK_UNINTERRUPTIBLE：睡眠等待 I/O 完成等，不可被信号中断
- TASK_STOPPED：被 SIGSTOP 等信号停止
- TASK_ZOMBIE：已退出但父进程尚未 wait()
上下文切换（context switch）保存当前任务的寄存器状态、栈指针、程序计数器等，然后恢复目标任务。在 Linux 中，上下文切换由 schedule() 函数触发，常见场景包括：
- 时间片耗尽（tick 中断中检测 need_resched 标志）
- 任务主动让出 CPU（cond_resched()、schedule()）
- 任务进入睡眠（wait_event、down_semaphore 等）
- 从中断/异常返回用户态前检查 TIF_NEED_RESCHED 标志
第二章：CFS 完全公平调度器——红黑树与 vruntime
2.1 设计哲学
CFS（Ingo Molnár 设计，2.6.23 引入）的核心思想极其优雅：通过维护每个任务的虚拟运行时间（vruntime），让所有任务的 vruntime 尽可能保持一致，即实现"完全公平"。
CFS 不使用时间片（timeslice）概念，而是将所有可运行任务按 vruntime 排列在红黑树中，每次选择 vruntime 最小的任务运行。当一个任务运行时，其 vruntime 不断增长；当它被抢占或自愿放弃 CPU 时，重新插入红黑树。长期得不到运行的任务 vrunime 最小，自然会被优先调度。
2.2 vruntime 的计算
vruntime 的计算公式为：
vruntime += (delta_exec * NICE_0_LOAD) / weight
其中：
- delta_exec：实际执行时间（纳秒）
- NICE_0_LOAD：nice 值 0 对应的权重（1024）
- weight：该任务的权重，由 nice 值映射
这意味着：低 nice 值（高权重）的任务，其 vruntime 增长更慢，因此在红黑树中位置偏左（值更小），能获得更多的实际 CPU 时间。例如，nice=-20 的任务权重为 88761，nice=+19 的任务权重为 15，前者每秒的 vruntime 仅增长约 1/8700，后者每秒增长约 70 倍，因此前者获得的 CPU 时间大约是后者的 8700 倍。
2.3 红黑树数据结构
CFS 的核心数据结构是 <kernel/fair.c> 中的 cfs_rq：
struct cfs_rq {
struct load_weight load; // 该队列的总权重
unsigned int nr_running; // 可运行任务数
u64 min_vruntime; // 队列中最小的 vruntime（单调递增）
struct rb_root_cached tasks_timeline; // 红黑树根节点
struct sched_entity *curr; // 当前正在运行的任务
// ... NUMA 相关字段
};
struct sched_entity {
struct load_weight load; // 该 entity 的权重
struct rb_node run_node; // 红黑树节点
u64 vruntime; // 虚拟运行时间
u64 exec_start; // 上次开始执行的时间
u64 sum_exec_runtime; // 总实际执行时间
u64 prev_sum_exec_runtime; // 切换出去时的执行时间
u64 vruntime; // 核心：虚拟运行时间
// ...
};
红黑树的关键操作时间复杂度为 O(log n)，插入/删除都非常高效。选择下一个任务只需取红黑树最左节点，而 Linux 通过 leftmost 缓存（rb_leftmost）将其优化到 O(1)。
2.4 CFS 调度流程
CFS 的主要调度流程如下：
schedule()
→ __schedule()
→ pick_next_task_fair() // 遍历调度类，选择下一个任务
→ pick_next_entity() // 取红黑树最左节点
→ set_next_entity() // 标记为 curr
→ put_prev_entity() // 将前一个任务重新插入红黑树
→ context_switch() // 上下文切换
时钟中断（tick）触发的周期性调度：
scheduler_tick()
→ task_tick_fair()
→ entity_tick()
→ if (delta_exec > ideal_runtime) // 检查是否运行超过理想时间
resched_curr(rq) // 设置 TIF_NEED_RESCHED 标记
→ update_min_vruntime() // 更新 min_vruntime
ideal_runtime 的计算方式决定了 CFS 的"延迟目标"（sched_latency，默认 6ms 在 HZ=250 下）。ideal_runtime = sched_latency / nr_running，即理想情况下每个任务在一个延迟周期内应分配到的 CPU 时间。
2.5 CFS 的 Group Scheduling 与 cgroup 集成
CFS 支持层级化调度：通过 task_group 可以将用户空间划分为不同的 CPU 控制组（cgroup），每个 cgroup 有独立的调度实体。这在容器编排（Docker/Kubernetes）中至关重要：
// 查看进程所属的 cgroup
$ cat /proc/self/cgroup
12:cpuset:/
11:cpu,cpuacct:/user.slice/user-1000.slice
// 设置 cgroup 的 CPU 配额（每 100ms 周期内最多用 50ms）
$ echo 50000 > /sys/fs/cgroup/cpu/mygroup/cpu.cfs_quota_us
$ echo 100000 > /sys/fs/cgroup/cpu/mygroup/cpu.cfs_period_us
2.6 CFS 的局限性
CFS 虽然优雅，但在某些场景下存在问题：
- 延迟抖动（Latency Jitter）：当一个长时间睡眠的任务醒来时，其 vruntime 远低于当前红黑树中的值（因为 min_vruntime 在它睡觉时一直增长，但不会低于它的 vruntime），这个"睡眠者"会霸占 CPU 一段时间直到追平，导致其他运行中任务被饿死。虽然 CFS 通过 vruntime 的 clamping 机制（不能在 min_vruntime 以下）部分缓解，但在极端场景下仍然明显。
- 交互式任务识别滞后：CFS 通过检查任务的睡眠行为来判断交互性，但对突发型交互任务（如游戏、GUI 应用）的识别仍有延迟。
- NUMA 负载均衡的权衡：在 NUMA 系统上，缓存亲和性与负载均衡之间的平衡非常微妙，CFS 经常在不必要的情况下跨 NUMA 节点迁移任务，导致远程内存访问的延迟惩罚。
第三章：EEVDF——Linux 6.6 的新一代调度算法
3.1 调度算法的"圣杯"问题
EEVDF（Earliest Eligible Virtual Deadline First）解决的问题是：在保证公平性的前提下，严格控制每个任务的调度延迟上界。
在实时调度理论中，EDF（Earliest Deadline First）是单处理器上最优的调度算法——如果一组任务可调度，EDF 一定可以调度成功。EEVDF 是 EDF 在通用任务调度中的扩展，通过引入 eligible time（合格时间） 的概念，在延迟和公平之间取得平衡。
3.2 EEVDF 核心概念
EEVDF 引入了三个关键时间概念：
- Virtual Time（虚拟时间）vt：与 CFS 的 vruntime 类似，按权重加权的执行时间
- Lagged Virtual Time（滞后虚拟时间）：为了确保新唤醒任务不会被过度惩罚，EEVDF 引入了 lag 值 = virtual_runtime - eligible_time
- Virtual Deadline（虚拟截止时间）vd：vt + slice，其中 slice 是该任务在一个延迟周期内应获得的 CPU 份额
EEVDF 选择 eligible_vd 最小 的任务运行，即最紧迫的未完成任务优先。
3.3 EEVDF 的 Lag 机制详解
Lag 是 EEVDF 最核心的创新。当一个任务在 CPU 上运行时，其 lag 为正（获得了 CPU 时间）；当它睡眠时，lag 为负（落后于公平份额）。EEVDF 通过以下方式保持 lag 在合理范围内：
// 任务运行时，计算 lag
lag = avg_vruntime - entity_key(se)
// 唤醒任务时，补偿 lag
if (lag < 0) {
// 睡眠时间太长，lag 过负，需要补偿
// 但设置 lag 下限防止过度补偿
lag = max(lag, -sysctl_sched_latency);
}
se->vruntime = clamp(se->vruntime, se->min_vruntime, avg_vruntime);
这与 CFS 的 min_vruntime clamping 不同：EEVDF 通过精确控制 lag 值，确保睡眠者醒来后不会狂吃 CPU。
3.4 EEVDF 与 CFS 的兼容共存
Linux 6.6 内核引入了 EEVDF 作为实验性调度器，通过内核启动参数sched_idle/ toggling：
// 查看当前调度器类型
$ cat /proc/sys/kernel/sched_itmt_enabled // Intel ITMT 相关
// 内核启动参数控制
// sched_fair_ext=1: 使用 sched_ext (BPF 可扩展调度器)
// 默认 CFS 仍然可用
EEVDF 替代 CFS 后的性能改善主要体现在：
- 延迟标准差降低 30-50%
- 消除了"长时间睡眠者醒来后霸占 CPU"的问题
- 在压力负载下尾部延迟（P99/P999）显著改善
第四章：多核调度与负载均衡
4.1 运行队列与调度域
每个 CPU 核心有自己的运行队列（rq），并通过调度域（sched_domain）组织成层级结构，覆盖从 SMT 线程到跨 NUMA 节点的不同拓扑：
Domain Hierarchy:
┌─────────────────────────────────────────────┐
│ NUMA Domain (跨 Socket 负载均衡) │
│ ┌───────────────────────────────────┐ │
│ │ Package Domain (同一 Socket) │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ MC Domain (同一 Core) │ │ │
│ │ │ ┌───────────────────┐ │ │ │
│ │ │ │ SMT Domain (线程) │ │ │ │
│ │ │ └───────────────────┘ │ │ │
│ │ └─────────────────────────┘ │ │
│ └───────────────────────────────────┘ │
└─────────────────────────────────────────────┘
每一层由 sched_domain 结构体描述，包含：balance interval、busy factor、min/max interval 等参数，控制负载均衡的频率和强度。
4.2 负载均衡的三种触发方式
负载均衡在以下时机触发：
- Periodic Balance：时钟中断中，每个调度域有自己的 balance interval。越高层的域（NUMA），间隔越长（因为迁移成本高）。
- Idle Balance：一个 CPU 变为空闲时，主动从其他 CPU 拉取任务。这是消除"空闲 CPU + 忙 CPU"不平衡的最快方式。
- Newidle Balance：创建新 fork 时，选择一个最小负载的 CPU 放置新任务（select_task_rq_fair）。
4.3 NUMA 感知调度（NUMA Balancing）
现代多路服务器的 NUMA 架构使得内存访问延迟差异巨大：访问本地内存约 70ns，跨 Socket 内存访问约 130ns（约 2x 延迟）。Linux 通过以下 NUMA 感知调度策略优化：
- AutoNUMA（NUMABalancing=1）：内核在每个 tick 中通过缺页中断扫描页表，统计每个页被哪个 CPU 访问最频繁，迁移页面到访问最频繁的 NUMA 节点。
- Task Placement：选择新任务运行位置时，优先考虑内存所在节点。
- NUMA Faults：通过 /proc/[pid]/numa_maps 监控缺页迁移。
// 查看 NUMA 拓扑
$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31 64-95
node 0 size: 128818 MB
node 1 cpus: 32-63 96-127
node 1 size: 129024 MB
node distances:
node 0 1
0: 10 21
1: 21 10
// 查看进程的 NUMA 内存分布
$ cat /proc/1234/numa_maps | head -20
4.4 SMT（超线程）与调度
在 Intel Hyper-Threading / AMD SMT 架构上，两个逻辑核共享一个物理核心的大部分执行资源。CFS 通过以下机制避免 SMT 上的资源争抢：
- Core Scheduling：仅在两个逻辑核上运行同一安全域的任务，防止侧信道攻击
- SMT Balancing：当一个物理核上的两个逻辑核都忙时，考虑将任务迁移到空闲物理核
- ITMT（Interference-Aware SMT-aware MultiThreading）：Intel 平台驱动，通过 P/E 核区分不同性能级别的任务
第五章：实时调度类——SCHED_FIFO 与 SCHED_RR
5.1 实时调度器设计
Linux 的实时调度类（rt_sched_class）提供两种调度策略：
- SCHED_FIFO：先进先出，不使用时间片，高优先级任务运行直到主动让出或抢占
- SCHED_RR：轮转法，同优先级任务间按时间片轮转
实时任务有 1-99 的优先级（数值越大优先级越高），可以通过 sched_setscheduler() 设置。
5.2 实时任务的注意事项
使用实时调度必须非常小心：一个高优先级的 SCHED_FIFO 任务如果不主动让出 CPU（例如进入死循环），将会永远霸占该 CPU 核心，导致所有低优先级任务饿死。常见解决方法是：
// 限制实时任务最大运行时间
$ echo 950000 > /proc/sys/kernel/sched_rt_runtime_us // 95% 时间给 RT 任务
$ echo 1000000 > /proc/sys/kernel/sched_rt_period_us // 1 秒周期
// 剩余 5% 时间留给普通 CFS 任务，防止 RT 任务彻底饿死系统
5.3 SCHED_DEADLINE——基于 EDF 的实时调度
Linux 3.14 引入了 SCHED_DEADLINE 调度策略，基于 EDF 和 CBS（Constant Bandwidth Server）算法：
struct sched_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);
CBS 算法通过跟踪每个任务的运行时预算，确保在 period 内不超过 runtime，且满足 deadline 约束。这是保证嵌入式和多媒体应用确定性延迟的最佳选择。
第六章：性能监控、调试与生产调优
6.1 调度器性能分析工具
Linux 提供了丰富的工具来观察和分析调度器行为：
// 1. perf sched —— 记录和报告调度事件
$ perf sched record -- sleep 10
$ perf sched latency // 显示调度延迟分布
$ perf sched map // 显示 CPU 使用时间线
$ perf sched script // 导出完整调度事件记录
// 2. sched_debug —— 运行队列状态
$ cat /proc/sched_debug | head -40
$ cat /proc/schedstat // 调度统计（每个 CPU）
// 3. ftrace —— 追踪调度器函数
$ cd /sys/kernel/debug/tracing
$ echo 1 > events/sched/enable
$ echo 1 > events/sched/sched_switch/enable
$ cat trace
// 4. BPF 工具 —— 高级调度分析
$ bpftrace -e 'tracepoint:sched:sched_switch { @[args->next_comm] = count(); }'
$ execsnoop-bpfcc // 追踪短命进程
// 5. schedstat 统计数据
$ cat /proc/schedstat
version 15
timestamp 4294667770
cpu0 0 0 0 0 0 123456789 456789012 0 0 0
domain0 ...
6.2 关键性能指标（KPIs）
评估调度器性能的关键指标：
- 调度延迟（Scheduling Latency）：从唤醒事件到实际运行的时间差，P50/P99/P999 分位数更重要
- 运行队列深度（Run Queue Depth）：rq->nr_running，超过 CPU 数表示争抢
- 上下文切换率（Context Switch Rate）：vmstat/sar -w 中的每秒切换数
- CPU 迁移次数（Migrations）：perf sched stat 中显示的跨 CPU 迁移
- CPU 利用率分布：用户态/内核态/空闲/等待 I/O 的比例
6.3 生产环境调优参数
// CFS 调节
sysctl kernel.sched_latency_ns=6000000 // CFS 延迟目标
sysctl kernel.sched_min_granularity_ns=750000 // 最小粒度
sysctl kernel.sched_wakeup_granularity_ns=10000000 // 唤醒粒度阈值
sysctl kernel.sched_migration_cost_ns=500000 // 迁移成本估计
// NUMA 调节
sysctl kernel.numa_balancing=1 // 启用 AutoNUMA
sysctl kernel.numa_balancing_scan_delay_ms=1000 // 扫描延迟
// 实时限制
sysctl kernel.sched_rt_runtime_us=950000 // RT 任务最大占用时间比例
// 能效
sysctl kernel.sched_energy_aware=1 // 启用 EAS（能效感知调度）
6.4 容器调度——CPU 绑核与配额
在容器化环境中，调度问题变得更为复杂。以下是常见的调优策略：
// 1. CPU 绑核（CPU Affinity）
$ taskset -cp 0-7 1234 // 将 PID 1234 绑定到 CPU 0-7
$ docker run --cpuset-cpus="0-7" app // Docker 绑核
// 2. CPU 份额
$ docker run --cpu-shares=512 app // 相对权重 512（默认 1024）
// 3. CPU 配额（hard cap）
$ docker run --cpus="2.5" app // 相当于 quota=250000 period=100000
// 4. Kubernetes 中使用 CPU Manager
// cpuManagerPolicy: static —— 独占核心分配
// guaranteed Pod（requests == limits）获得独占 CPU
// burstable Pod 共享剩余 CPU
6.5 常见问题排查
问题 1：高负载但 CPU 利用率低
通常是因为任务频繁进入睡眠（I/O 密集型），或 cpu affinity 限制了任务只能在不多的核上运行。检查：sar -q（运行队列长度）、taskset -p。
问题 2：高上下文切换率
vmstat 中 cs 列持续居高不下。可能原因：过多活跃线程、锁竞争导致频繁抢占。检查：perf sched latency、pidstat -w。
问题 3：NUMA 远程访问过高
numastat 显示大量跨节点访问。解决：numactl --interleave=all、设置内存策略、或使用 mbind() 手动分配。
问题 4：虚拟机调度的双调度问题
客户机（Guest OS）和客户机任务之间存在两层调度：宿主机调度 vCPU，客户机调度 guest 线程。这会导致 vCPU 阻塞时抢不到 CPU 时间、或 CPU-bound 与 I/O-bound 任务共存时的优先级倒置。解决方案：使用 vcpu pinning + real-time KVM + 主机 RT CGroup。
第七章：sched_ext——BPF 可扩展调度器
7.1 设计动机
虽然 CFS 和 EEVDF 在不断改进，但它们的通用性设计无法满足所有场景。例如：
- HPC/AI 训练集群需要全局 FIFO 调度而非公平调度
- 数据库（MySQL/PostgreSQL）希望调度器感知 NUMA 拓扑和连接亲和性
- 游戏需要微秒级的帧渲染调度
sched_ext（Linux 6.12 引入）允许用户空间通过 BPF 程序实现自定义调度器，运行时加载/卸载，无需重启内核。
7.2 基本架构
struct scx_ops {
void (*select_cpu)(struct task_struct *p, s32 prev_cpu, u64 wake_flags);
void (*enqueue)(struct task_struct *p, u64 enq_flags);
void (*dispatch)(s32 cpu, struct prev_task_struct *prev);
void (*running)(struct task_struct *p);
void (*stopping)(struct task_struct *p, bool runnable);
// ...
};
// 用户态加载 BPF 调度器
$ scx_rustland // 社区 BPF 调度器示例
$ scx_lavd // 以延迟为导向的调度器
$ scx_layered // 分层调度
目前社区有多个基于 sched_ext 的调度器实现：
- scx_rustland：Rust 编写的用户态调度器
- scx_lavd：Latency-critical Aware Virtual Deadline，针对交互式延迟优化
- scx_layered：基于层级优先级域，适合异构工作负载
- scx_nest：NUMA 感知的层次调度器
第八章：未来展望
8.1 EEVDF 完全取代 CFS
Linus Torvalds 在 Linux 6.6 中将 EEVDF 设为默认调度器，彻底替代了 CFS。经过一年多的用户反馈和社区测试，EEVDF 在延迟控制上的优势已被广泛验证。随着 6.12 LTS 的发布，EEVDF 的稳定性和性能将进一步打磨，而 CFS 将逐步进入维护模式。
8.2 CXL 内存与调度器
Compute Express Link（CXL）是一种高速互连协议，能够将内存扩展设备（如 CXL.attached DRAM、CXL SSD）连接到 CPU。CXL 的引入意味着：
- 内存有了更多层级（DRAM → CXL-DRAM → CXL-SSD），访问延迟递增
- 调度器需要感知"任务运行在什么延迟等级的内存上"
- 未来调度器可能需要与内存分层（Memory Tiering）协同优化
8.3 异构计算的调度挑战
随着异构计算（CPU + GPU + DPU + NPU）的普及，调度器面临新问题：
- GPU 任务如何与 CPU 调度协同（当前通过用户态 CUDA stream 提交）
- DPU 上的网络处理如何被 CPU 调度器感知
- Chiplet 架构下的核间延迟变化
Linux 内核社区正在讨论将这些加速器纳入统一管理框架，未来可能出现"Universal Scheduler"，统一管理所有计算资源。
8.4 Rust-for-Linux 与调度器安全
调度器是内核中最复杂的模块之一，C 语言的内存安全问题一直是个隐患。Rust-for-Linux 项目正在探索用 Rust 重写调度器部分逻辑，特别是 BPF 调度器适配层（sched_ext）：
- 所有权模型可以消除 use-after-free、double-free 等内存 bug
- 并发安全由编译器检查（Send/Sync trait）
- 但调度器性能要求极高，Rust 实现需要与 C 版本竞争基准测试
第九核：内核源码阅读指南
9.1 关键文件导航
kernel/sched/
├── core.c // 主调度代码：schedule()、__schedule()、wake_up_process()
├── fair.c // CFS 调度器（Linux 6.6 前）
├── core_sched.c // Core 调度（防侧信道）
├── cpudeadline.c // Deadline 调度类的 CPU 选择
├── rt.c // 实时调度类
├── idle.c // 空闲调度类
├── stop_task.c // Stop 调度类
├── sched.h // 主要头文件：sched_class、task_group 等定义
├── pelt.c // Per-Entity Load Tracking
├── debug.c // sched_debug 实现
├── fair.c // CFS 实现
├── stats.c // 调度统计
├── wait.c / wait_bit.c // 等待队列机制
├── completion.c // 完成量（同步原语）
├── swait.c // 简单等待队列
├── cpupri.c // CPU 优先级
├── topology.c // 拓扑初始化
├── autogroup.c // 自动分组
├── membarrier.c // 内存屏障系统调用
└── features.h // 调度特性开关
9.2 推荐的阅读顺序
学习 Linux 调度器源码的建议路线：
- 从 kernel/sched/core.c 开始，理解 schedule() 主循环和上下文切换流程
- 阅读 wake_up_new_task() 和 try_to_wake_up()，理解任务唤醒路径
- 研究 CFS 的 entity_before()、__enqueue_entity()、__dequeue_entity()
- 学习 pick_next_entity() 中的 pick_first 逻辑和 cfs_rq 的内部结构
- 理解 task_tick_fair() 中的 preempt 检查逻辑
- 进入 load balance 代码，研究 load_balance() 和 detach_tasks()
- 阅读 SCHED_DEADLINE 的 CBS 算法实现（deadline.c）
- 探索 sched_ext 的 BPF prog 加载和 dispatch 框架
第十章：总结与核心要点速查
快速回顾本文核心知识点：
| 概念 | 说明 | 关键参数 |
|---|---|---|
| vruntime | 按权重加权的虚拟执行时间 | min_vruntime、sched_latency |
| sched_class | 调度器类的优先级链表 | stop > dl > rt > fair > idle |
| sched_domain | NUMA/SMT 层级拓扑 | balance_interval、busy_factor |
| EEVDF | 基于 EDF 的公平调度替代 CFS | lag、virtual deadline |
| AutoNUMA | 自动 NUMA 页迁移 | numa_balancing_scan_delay_ms |
| Cgroup CPU | CPU 配额隔离 | cfs_quota_us / cfs_period_us |
Linux 内核调度器是一个持续演进的复杂系统。从 CFS 的红黑树公平调度，到 EEVDF 的 deadline 驱动，再到 sched_ext 的 BPF 可编程调度，每一次演进都在试图突破"通用"与"专用"之间的壁垒。理解这些核心机制，不仅对内核开发有帮助，对高性能计算、容器编排、实时系统等应用领域同样至关重要。
建议读者在理解理论的基础上，通过 perf sched、bpftrace、/proc/sched_debug 等工具亲手实验，在真实环境中验证这些机制的表现，从而建立扎实的调度器实战能力。
发表评论 取消回复