Infinity Scheduler：抛弃 sched_ext，重回内核原生的 EEVDF 调度器

TL;DR： 开发者 Galih Tama（之前做 scx_flow 的）发布了 Infinity Scheduler——一个直接修改 CFS 和 RT 调度器的内核补丁集，彻底抛弃了 BPF/sched_ext 路线。核心思想：用指数移动平均（EMA）追踪每个任务的运行时历史，CPU 密集型任务的调度时间片可缩小到 400µs 地板，交互式任务保持完整份额，RT 任务同样受 EMA 调优。目前支持 Linux 6.18 LTS、7.0、7.1。

一、背景：调度器之争的三个流派

Linux CPU 调度器在 2025-2026 年进入了\"百花齐放\"的时代，但方向上可以分为三个流派：

流派 1：sched_ext / BPF 调度器（\"外挂党\"）

通过 Linux 的 sched_ext（可扩展调度）框架，用 BPF（Berkeley Packet Filter）程序在运行时动态替换调度策略，不需要修改内核代码。代表作品：

• scx_lavd——延迟感知虚拟 deadline
• scx_rusty——Rust 写的调度器
• scx_bpfland——BPF 驱动的调度器集合
• scx_flow——Galih Tama 之前的作品

优势：不用编译内核、热加载、低门槛。

劣势：Phoronix 文章里明确指出了——\"fundamental limitations\"（根本性限制），包括 BPF 验证器误判（false positives），高负载下的可靠性问题。

流派 2：调度器插件 / 独立调度域（\"中间派\"）

• 如 Project C / MuQSS（Con Kolivas 的多年坚持）
• 部分独立于主线，部分依赖内核接口

流派 3：直接修改内核调度核心（\"硬改党\"）← Infinity Scheduler 在此

直接打补丁到 CFS（完全公平调度器）和 RT（实时调度器），不走 BPF、不走 sched-ext。这是最\"硬核\"的做法——你需要重新编译内核，但换来的是没有抽象层的性能损耗和完全的调度控制权。

二、Infinity Scheduler 的核心技术EMA（指数移动平均）追踪

核心创新其实不复杂：用一个指数移动平均（Exponential Moving Average）来追踪每个任务的最近运行时历史。

EMA_new = α × runtime_recent + (1 - α) × EMA_old

• α 是平滑因子，决定对最近运行时的敏感度
• 对每个任务维护一个独立的 EMA 值

时间片动态调整

基于 EMA 值，调度器做两件事：

1. CPU 密集型任务

长时间占 CPU 的任务的 EMA 值会升高 → 调度器主动缩小它的时间片（time slice），最低可到 400µs（0.4 毫秒）。

这意味着一个干 heavy computing 的进程，每次只能跑 400 微秒就得让位。粒度比 CFS 默认的时间片（4-15ms 量级）细了一个数量级。

2. 交互式任务

交互式任务（编辑器、终端、GUI 应用）的 EMA 值低 → 保留完整的时间片。它们几乎感觉不到调度竞争。

vslice（虚拟时间片）优先

低 EMA 值的任务（交互式/新唤醒）在 EEVDF（最早虚拟截止时间优先）树中获得 50% 更短的 vslice。这意味着它们的 deadline 被提前，更容易被选中执行。

futex 等待绕过

Infinity Scheduler 在 pick_eevdf() 函数中增加了一个 futex-waiting bypass——等待 futex 锁的任务在下一次调度点可以被立即抢占（preempted），不需要等到时间片用完。

这对锁竞争频繁的场景（数据库、Web 服务器、并发框架）是显著的优化。

RT 任务同样受 EMA 调优

连 RT（实时）调度类的任务都受到 EMA 的 queue placement modulation（队列位置调优）——内核之前很少对 RT 任务做这种动态调整。

三、为什么抛弃 sched_ext？

Galih Tama 的做法在圈内是有点争议的——他之前是 scx_flow 的作者，sched_ext 路线的主力开发者之一。现在他反过来批评 sched_ext 的\"根本性限制\"，并回归主线内核的 CFS/RT 修改。

原因很明确：

1. BPF 验证器的误判：在高负载下，BPF 验证器会拒绝合法的调度程序
2. 性能损耗：BPF 抽象层本身有开销，JIT 编译后的 BPF 程序跑得再快也没有原生内核代码快
3. 可靠性问题：sched_ext 调度的异常回退（fallback）机制在高并发场景下不够稳定
4. 功能受限：BPF 程序无法直接访问内核内部数据结构，能做事情的边界有限

这个选择非常反映现实：BPF 让内核编程变简单了，但简单不等于强大。

四、Infinity Scheduler 适合谁？适合

• 重度编译/构建服务器：大量 CPU 密集型进程竞争时，Infinity 的细粒度时间片可以让交互式 SSH 操作不卡顿
• 桌面 Linux 用户：跑编译时还能流畅用浏览器和编辑器
• 低延迟交互系统：需要保证交互式任务优先响应

不适合

• 大规模数据中心：需要经过广泛的 benchmark 验证和稳定性测试
• 嵌入式/物联网设备：补丁集增加的内核复杂度可能带来维护负担
• 需要和上游保持同步：Infinity 目前是独立补丁集，没有合入主线计划

极低延迟 vs. 高吞吐

这里有一个你需要注意的权衡：时间片降到 400µs 在提升交互体验的同时，意味着更多的上下文切换。在 CPU 密集型的纯计算任务上——比如一个运行 10 分钟的 CFD（计算流体力学）模拟——更多的调度切换会引入额外的 cache miss 和 TLB 刷新，导致总运行时间增加。

Infinity Scheduler 默认选择偏向交互体验。如果你的工作负载主要是批处理计算，可以调高时间片地板值。

五、值得关注，但别急着打补丁

Infinity Scheduler 目前：

• 只支持 Linux 6.18 LTS、7.0、7.1 三个版本
• 是一个外部补丁集，没有进入主线
• GitHub 仓库可能还是私有的（Phoronix 给出了链接但公开搜不到）
• 还没有独立的性能 benchmark 数据（Phoronix 表示如果读者有兴趣就去跑测试）

EMA 追踪 + EEVDF 动态 deadline 调节这个方向是正确的。但调度器是操作系统里最难做对的部分——一场内核世界大战。在 Phoronix 跑出可靠 benchmark 之前，建议观望。

不过，作为 Linux 调度器\"从外挂回归内核原生\"的技术思潮转变的一个信号，Infinity Scheduler 值得每一个关心 Linux 底层的人关注。

━━━ ━━━ ━━━

后记： Linux 调度器的江湖从不缺新门派。从 CFS 到 EEVDF 到 sched_ext，再到现在的 Infinity Scheduler 重回内核原生路线——每个流派都在说\"我找到了更好的路\"。技术的魅力就在于此：没有完美的调度器，只有不同 trade-off 之间的取舍。

━━━ ━━━ ━━━

*欢迎关注 LeisureLinux，获取更多深度技术解读。*

内核纪元新篇章：Linux 7.0 深度技术解析与架构演进

性能跃迁：在 Debian 13 上驾驭 Linux 7.0 极速内核（CachyOS & XanMod 实践）

技术前瞻：Fedora 44 下周正式发布，底层架构有哪些值得关注的重大变更？

进阶避坑：深度解析 ethtool 统计触发 RTNL 锁竞争导致的线上 RPC 抖动