别只盯着 MySQL 配置了——Linux Cache Aware Scheduling 才是 2026 年最大的性能红利

核心观点

Linux 7.2 刚刚合入了 Intel 贡献的 Cache Aware Scheduling 基础框架（LLC 域内聚合）。Hygon 紧接着在此基础上提交了一组层次化扩展补丁（RFC 状态），将 MySQL 写事务吞吐量推高 360%。这不是魔术——这是 Linux 调度器从"LLC 域内优化"迈向"全拓扑感知"的关键一步。

一、痛点：大模型时代，CPU 却在"等缓存"

你有没有想过一个问题：现代 CPU 几百个核心，为什么跑数据库有时候还不如把线程数锁死？

答案藏在 缓存一致性 里。

当你的数据库线程分散在不同的 LLC（Last-Level Cache，末级缓存）域上，每一行数据的修改都需要跨芯片传输一致性消息。在双路/四路服务器上，这种开销可以吃掉 50% 以上的性能。更糟糕的是——操作系统调度器对此一无所知，它只关心负载均衡，不关心你的两个线程是否在抢同一片数据。

这就是 Cache Aware Scheduling 要解决的问题。

二、CAS 是什么？为什么它这么重要？

2.1 核心思想

CAS 的原理可以浓缩为一句话：把共享数据的任务聚到同一个缓存域。

在 Linux 7.2（2026 年 5 月）合入的 CAS 基础框架（由 Intel 工程师 Tim Chen、Chen Yu、Peter Zijlstra 贡献），在调度层引入了一个新的优化目标：当 task A 和 task B 通过某种机制（比如同属一个 cgroup，或共享内存页）被标记为"相关"时，调度器会优先将它们放在同一个 LLC 域上。

这意味着：

• 读多写少
  的工作负载：共享数据仍在 LLC 中，延迟极低
• 写密集
  的工作负载：缓存一致性流量被限制在单个 LLC 域内，不再跨芯片广播

2.2 基础 CAS 的致命局限——也是 Hygon 要解决的问题

然而，Intel 的基础实现在架构上有一个硬边界：任务聚合只在一个 LLC 域内有效。

一旦工作负载超出单个 LLC 的容量，调度器就回到传统行为——任务被分散到多个 LLC 域，缓存局部性完全丢失。

在多 chiplet 架构上，这个问题被急剧放大。以 Hygon C86-7490 为例，它有 4 个 chiplet，每个 chiplet 有自己的 LLC，容量有限。一个稍大的 MySQL 连接池就可以轻松溢出单个 LLC，导致性能断崖下跌。

注意：以下讨论的 Hygon 扩展补丁目前仍是 RFC 状态（请求评审，尚未合入主线），与 Linux 7.2 已合入的基础 CAS 是两个不同阶段的工作。

三、Hygon 的层次化扩展：从 “LLC 孤岛” 到 “拓扑河流”

⚠️ 状态说明：Hygon 这套补丁于 2026 年 6 月 25 日提交为 RFC（Request for Comments），正在内核邮件列表接受评审，尚未合入任何 Linux 主线版本。下面的技术分析和性能数据均基于该 RFC。

3.1 方案总览

Hygon 工程师 Jianyong Wu 在 2026 年 6 月 25 日向内核邮件列表提交了 RFC 补丁系列，标题为：

“sched: Extend cache-aware scheduling into topology-aware scheduling”

理解这个方案的核心，只需要记住一个词：Hierarchy（层次）。

3.2 动态域扩展

传统 CAS 的聚合是固定的——进去 LLC 就不出来。Hygon 的方案是动态的：

关键创新在于：聚合域随负载动态伸缩，负载下降时自动收缩回 LLC。

3.3 新指标：affinity-gain

为了在不同域之间做出最优迁移决策，补丁引入了 affinity-gain（亲和增益） 指标。它衡量将一个任务迁移到目标 runqueue 后，缓存收益与迁移成本的比值。调度器选择增益最高的源 runqueue 进行拉取。

配合新增的可调参数 aggr_tolerance（测试取值 90），开发者可以微调"多快扩展到更大域"的激进程度。

3.4 与 NUMA balancing 的协同

这是一个值得展开的设计细节。

NUMA balancing 处理的是内存放置——它把页面迁移到访问它的 CPU 所在 NUMA 节点。CAS 处理的是任务放置——它把任务迁移到数据所在的缓存域。

两者的优化目标是正交但互补的。补丁第 7 个 commit 明确让 CAS 在调度决策上优先于 NUMA balancing：先聚任务，再聚内存，两条路径最终收敛到同一个 NUMA 域。

四、实测数据：不止是 MySQL

4.1 MySQL（最亮眼的数字）

测试场景：Hygon 双路服务器（每路 6 NUMA 节点，每 NUMA 2 LLC，每 LLC 8 核，2 SMT/核）。

360% 的解释：64 线程时，基线调度器将写事务分散到多个 NUMA 节点，每一次 UPDATE 都需要跨 chiplet 做缓存一致性同步，延迟暴增。层次化 CAS 将相关事务聚合在有限域内，一致性流量被限制在一个 chiplet 内部。

4.2 其他基准

4.3 代价

低线程数（< LLC 容量）有小幅回退，最高 -22.9%。原因是层次化策略在 LLC 内容量足够时也不如原始 CAS 那么激进地聚合。这是可预期的取舍，也是 aggr_tolerance 参数存在的意义。

五、与 AMD/Intel 多 chiplet 架构的联动

这一补丁对 AMD 的 EPYC（多 CCD/多 LLC）同样有效。实际上，chiplet 架构越激进，这个补丁的收益越大：

• AMD EPYC Bergamo: 16 CCD，每个 CCD 仅 8-16 核小 LLC
• Intel Xeon Granite Rapids: 多 tile 架构
• AmpereOne: 192 核，多 cluster

Hygon 第一个提了这个方案，是因为它在自己的 C86 系列上痛感最深——但收益是全行业共享的。

六、补丁概览与社区反应

8 个补丁，5 个文件，+345 / -73 行。代码量不大，核心逻辑在 sched/fair.c 中的迁移决策路径上。

当前状态：RFC，Linux 7.3 窗口期可能会正式合入。

七、总结展望

Cache Aware Scheduling 从 Intel 的 LLC 域优化到 Hygon 的全拓扑层次化扩展，代表了一个清晰的趋势：Linux 调度器正在从"负载均衡器"进化为"拓扑感知的协同管理器"。

对于运行在大型多 chiplet 服务器上的工作负载（数据库、消息队列、缓存服务），这一系列优化可能是近年来最值得关注的内核变更。

如果你还认为调度器只需要把 CPU 跑满就行——该更新认知了。