Linux 调度器有哪些性能相关的改动

Linux 调度器性能相关改动详解

Linux 调度器是内核中最核心、演进最活跃的子系统之一。从早期简陋的 O(n) 调度器到今天支持 BPF 可编程扩展的 sched_ext，性能优化贯穿了每一次重大重构。以下按演进阶段和核心特性两个维度展开分析。

一、调度器架构的三大跨越

二、里程碑式性能改动详解

1. CFS vtime 调度与红黑树

• 原理：每个 task 维护 vruntime（虚拟运行时间），CFS 总是选择红黑树最左节点（vruntime 最小的进程）运行。
• 关键收益：
  • 对交互式任务天然友好（休眠后 vruntime 不变，醒来后优先运行）
  • O(log N) 复杂度，进程数多时远优于 O(n)
• 数据结构：

  struct task_struct {
      struct sched_entity se;  // 调度实体
      u64 vruntime;            // 虚拟运行时间
  };
  // 红黑树根节点
  struct cfs_rq {
      struct rb_root_cached tasks_timeline;
  };
  

2. PELT (Per-Entity Load Tracking) - v3.8

• 背景：传统负载统计基于简单的时间片计数，无法精确反映瞬时负载变化。
• 原理：使用指数加权移动平均 (EWMA) 的半衰期衰减算法，以 1ms 为粒度累加负载，decay = load * y^n（y ≈ 0.978，32ms 半衰期）。

  load = 0
  every 1ms:
    load = load * y + running_time * scale
  

• 性能收益：
  • 调度器能准确感知 task 的真实负载贡献（而非简单采样）
  • 负载均衡精度提升 30%-50%，减少不必要的迁移
  • 为后续 EAS、CFS bandwidth control 提供基础
• 演进：PELT 后来扩展支持 util_est（v5.4），增加 avg_util（任务利用率预估），改善任务唤醒时的负载低估问题。

3. NUMA 调度与自动 NUMA 均衡 - v3.8 / v3.13

• 背景：NUMA 架构下，跨节点内存访问延迟远高于本地节点。
• v3.8 - NUMA scheduling foundation：调度器在负载均衡时优先将 task 保持在其所属 NUMA node。
• v3.13 - 自动 NUMA 均衡 (AutoNUMA)：
  • 周期性扫描 task 的页面，统计 page fault 的 NUMA node 来源
  • 当发现 task 频繁访问远端内存时，迁移页面到本地，或将 task 迁移到内存所在节点
  • 采用两种扫描模式：NUMA hinting faults + shared page interleaving
• 性能收益：
  • SPECjbb2005 等 NUMA 敏感型负载性能提升 15%~40%
  • 减少远程内存访问延迟
• 后续优化：
  • v4.18：numa_balancing=enable 默认开启
  • v5.6：NUMA-aware spread 策略优化
  • v6.1：sched/fair: Introduce preferred group 优化进程分组迁移

4. 调度类与优先级继承

Stop_Sched      -> 停止调度（最高优先级）
Deadline_Sched  -> SCHED_DEADLINE (EDF)
RT_Sched        -> SCHED_FIFO / SCHED_RR (优先级 1-99)
Fair_Sched      -> SCHED_NORMAL / SCHED_BATCH (CFS)
Idle_Sched      -> SCHED_IDLE

• SCHED_DEADLINE (v3.14)：基于 EDF + CBS (Constant Bandwidth Server) 算法：
  • 任务指定 runtime、deadline、period 三个参数
  • 调度器保证在 deadline 前完成执行
  • 适用于音视频编解码、工业控制等硬实时场景
  • 性能：比 RT 类调度更加可预测，CPU 利用率更高

5. 负载均衡优化（v4.x ~ v6.x 系列）

这是性能改动最密集的领域，积累了数十个关键补丁：

6. EAS (Energy-Aware Scheduling) - v4.x ~ v5.x 逐步成熟

• 背景：ARM big.LITTLE / DSU 架构下，需要兼顾性能与功耗。
• 原理：利用 PELT 计算的 util_avg，结合 Energy Model (EM) 选择能耗最优的 CPU 组合。
• 关键组件：
  • find_energy_efficient_cpu()：在唤醒时选择能耗最优 CPU
  • Capacity Aware 负载均衡：favor_capacity / prefer_sibling
• 性能与功耗收益（Google Pixel 数据）：
  • 轻负载场景：功耗降低 15%~25%，性能无下降
  • 中度负载：有效降低 EAS 场景的 task 抖动迁移
• 版本演进：
  • v4.2：EAS 基础框架引入
  • v5.0：energy model subsystem 独立
  • v5.8：EAS 默认在 arm64 启用
  • v6.1：FIT (Frequency Invariant Tracking) 支持，EAS 精度进一步提升
  • v6.5：EAS 支持 x86 平台

7. Core Scheduling (sched/core) - v5.14

• 背景：SMT (超线程) 芯片上共享 L1 cache 导致侧信道攻击风险。
• 原理：通过 cgroup/cpuset.sched.core_cookie 标记不同信任域，确保同一物理核心的两个超线程不同时运行不同信任域的 task。
• 性能收益与成本：
  • 安全性提升（防御 SMT 侧信道）
  • 无信任域隔离时性能无损
  • 有隔离场景：CPU 密集型负载降 5%~15%（取决于 HT 利用率）
  • 后续优化（v5.16、v6.2）大幅降低开销

8. sched_ext (BPF 调度器) - v6.12

• 原理：新增 EXT_SCHED_CLASS 调度类，允许通过 BPF 程序实现自定义调度策略，无需编译内核模块。
• 性能潜力：
  • Google 内部使用 BPF 调度器在数据中心实现尾部延迟降低 40%
  • ByteDance 使用 BPF 调度器优化数据库场景，吞吐量提升 20%~30%
  • 社区已实现多种 BPF 调度器：scx_layered、scx_rusty、scx_rustland 等
• 关键 API：
  • ops.select_cpu() - 选择初始 CPU
  • ops.enqueue() / ops.dequeue() - 入队/出队
  • ops.dispatch() - 调度逻辑
  • ops.tick() - 时钟中断处理

9. 调度延迟与响应时间优化

三、真实性能数据对比

注：以上数据综合自 LKML 讨论、Phoronix benchmark、Google/ByteDance 生产报告

四、关键配置文件与调优手段

# 查看当前调度策略
cat /sys/kernel/debug/sched_features
cat /proc/sys/kernel/sched_*

# 关键参数
sched_migration_cost_ns     # 迁移成本阈值
sched_nr_migrate            # 每 tick 最大迁移数
sched_util_clamp_min        # 最小利用率钳制
sched_util_clamp_max        # 最大利用率钳制

# CFS 调优
/proc/sys/kernel/sched_latency_ns   # 调度延迟目标
/proc/sys/kernel/sched_min_granularity_ns  # 最小调度粒度

# NUMA 调优
/sys/kernel/debug/sched/numa_balancing
/sys/kernel/debug/sched/numa_scan_period_min_ms

五、展望：性能优化趋势

1. sched_ext 生态繁荣：BPF 调度器将允许云厂商、数据库厂商针对自身负载定制最优调度策略
2. AI/ML 辅助调度：利用 PELT 预测模型做负载前瞻调度
3. 异构计算调度：CPU + GPU + NPU + DPU 统一调度框架
4. 调度域 (sched domain) 精细化：CXL 互联、内存池化后的 NUMA 拓扑感知增强
5. 抢占模型优化：Full PREEMPT vs PREEMPT_RT 的进一步收敛

如果您对某一项改动（如 AutoNUMA、EAS、sched_ext）有更深入的兴趣，我可以展开到具体的数据结构、代码路径或调优实践。

本页面由 MaxKB 问答记录自动导出，供 osperf content-ingestion skill 处理。