为什么一个“时间片”能折腾 Linux 十年?

如果你问一个刚接触 Linux 的同事：“进程为什么会被切走？”

答案大概率是：“因为时间片用完了。”

但如果你问一个内核工程师同样的问题，答案会变成：

因为调度器认为现在切走，比不切走对系统整体更公平。

Linux 调度器（CFS）从来不是一个简单的“定时器 + 轮转队列”，而是一套围绕公平性、吞吐、延迟、可预测性反复博弈的复杂系统。而“时间片（time slice）”正是其中最基础、却也最敏感的机制之一。

正因为如此，任何试图“临时延长时间片”的行为，都会天然触碰调度器最核心的设计原则。

而现在，一个历经十多年讨论、反复失败、数次重来的机制——Time Slice Extension（时间片扩展），终于在 Linux 6.20 ~ 7.0 周期，看到了进入主线的希望。

什么是时间片扩展？

时间片扩展不是抢占调度器的控制权，也不是提升优先级。

它的核心目标只有一个：

在“非常短暂、非常确定”的用户态临界区内，避免线程被不必要地抢占。

典型场景包括：

• 用户态自旋锁（user-space spinlock）
• 无系统调用的极短临界区
• 高并发、低延迟的数据结构操作
• RSEQ（Restartable Sequences）保护区间

这些场景有一个共同点：

一旦线程在临界区被抢占，系统整体性能反而下降。

举个运维同学更容易理解的例子：

• 线程 A 拿着一个用户态锁

• 线程 B 被调度上来，开始自旋等这个锁
• 但 A 因为时间片用完，被调度器切走

• 结果：CPU 白白空转，所有线程都在浪费时间

这是经典的“优先级反转 + 不必要抢占”问题，但发生在用户态，内核几乎无从感知。

Thomas Gleixner 的定义

Intel 旗下 Linutronix 的 Thomas Gleixner 在补丁中给出了一个非常精准的定义：

Time Slice Extension 是一种“机会主义（opportunistic）的优先级天花板”，

它不像传统优先级继承协议那样昂贵，

也不提供同等级别的强保证，

但能在关键时刻避免最糟糕的调度结果。

这段话信息量极大，我们拆开来看：

1. 不是完整的优先级继承协议

• 不会调整调度实体的 vruntime
• 不会重排 CFS 红黑树
• 不会改变任务的 nice / priority

所以它几乎不影响调度器的整体公平性模型。

2. 是“机会主义”的

• 只有在“刚好可以延长”的时候才延长
• 不承诺一定成功
• 不保证实时性

这点非常关键： 它不是 RT 特性，而是 best-effort 的优化机制。

为什么之前十年都“没搞成”？

说句实话，这个需求并不新。

早在十多年前，LKML 上就已经有人讨论过类似问题，但每一轮尝试几乎都卡在几个老问题上：

1. 用户态如何安全地告诉内核：“我现在很关键”

如果暴露一个系统调用：

• 开销太大
• 破坏临界区“无系统调用”的初衷

如果走隐式机制：

• 内核根本不知道你在干嘛

2. 如何防止滥用？

如果任何进程都能说：

“我现在很重要，别切我”

那调度器基本就废了。

3. 和 CFS 公平性模型天然冲突

CFS 的核心理念是：

虚拟运行时间（vruntime）决定公平，而不是你说你重要。

任何“特权延时”，都需要极其谨慎。

转折点：RSEQ

真正的突破点，来自 RSEQ。

RSEQ 是 Linux 提供的一种用户态机制，用于：

• 标记一段“可重启”的用户态代码
• 在被抢占或迁移 CPU 时，由内核帮你“回滚重来”

它已经被广泛用于：

• glibc
• jemalloc
• 数据库内核
• 高性能并发库

关键点在于：

内核已经“部分知道”你正在执行一个特殊的用户态临界区。

时间片扩展正是建立在 RSEQ 这个已有、受控、可验证的机制之上。

这让问题从：

“如何让用户态随便跟内核提要求”

变成了：

“如何在一个已经被内核认可的关键区间里，稍微放宽抢占条件”

补丁进入 tip/sched/core

在过去几个月里，时间片扩展补丁已经迭代到 v6。

而就在最近：

最新版本已经被合入 tip/tip.git 的 sched/core 分支

对于熟悉内核开发流程的同学来说，这一步意义重大：

• tip 分支是调度器改动的“准入门槛”

• 进入 sched/core，说明：

• 设计方向被认可
• 实现质量达到可维护标准
• 风险可控

这意味着：

它很可能会出现在下一个 merge window，随调度器改动一起提交给 Linus。

时间片扩展不会像 BPF 那样一夜爆红，也不会立刻改变你的运维日常。

但它非常 Linux：

• 长期讨论
• 反复失败
• 保守推进
• 一旦合入，就极难再被移除

如果你在生产环境里追求：

• 更低的尾延迟
• 更稳定的高并发行为
• 更少“看起来不合理”的性能抖动

那么，这个“等了十年的补丁”，值得你记住它的名字。