解决高并发下的锁竞争：腾讯提交 Linux 内核 Swap 优化方案

近日，Linux 内核社区迎来了一组受人关注的补丁更新。来自腾讯的工程师Kairui Song再次提交了针对 Swap子系统的重构补丁。

这并非Kairui Song第一次对 Linux 的内存管理系统“动刀”。早在 2024 年和 2025 年，他就曾在 Linux Plumbers 大会（LPC）上多次探讨过 Swap 分区的性能瓶颈。而这一次的补丁系列，旨在通过引入全新的“Swap Table”结构，彻底解决困扰内核多年的锁竞争和扩展性问题。

为什么 Swap 需要大改？

在很多人的印象里，Swap 是一个应急功能：当物理内存不足时，系统把暂时不用的数据挪到硬盘上。但在现代的大规模云计算和高并发环境下，Swap 的意义已经发生了变化。尤其是在使用高速 NVMe 硬盘和 zswap技术的今天，Swap 的读写速度大幅提升，原本被掩盖的软件架构瓶颈开始暴露。

目前 Linux 内核处理 Swap 的逻辑非常传统。它使用一种被称为“swap map”的机制，每个交换入口只占用 1 字节。这种设计的初衷是极度节省内存，在物理内存只有几百兆的时代非常有效。

但这种极简设计也带来了代价。随着核心数的增加，多个 CPU 同时访问 Swap 时会产生严重的锁竞争。特别是 si->lock 的全局锁，在重负载下几乎成了性能杀手。此外，随着 mTHP技术的引入，Swap 需要处理不同大小的内存页，原有的 4K 粒度管理方式显得捉襟见肘，容易产生碎片，导致大页分配失败。

“交换表”带来了什么？

腾讯工程师提出的“Swap Table”方案，本质上是让 Swap 管理结构不再局限于 1 字节的简单映射，而是引入了一个更具扩展性的索引框架。

根据最新的测试数据和补丁说明，第一阶段的重构已经显示出明显的收益：

1. 1. 性能提升：在 48 核 96 线程、128GB 内存的服务器上进行压力测试，Swap 子系统的吞吐量提升了 20% 到 30%。
2. 2. 核心负载优化：Redis 和 Valkey 等内存数据库在重负载下的吞吐量提升了约 6% 到 7%。
3. 3. 编译提速：在进行 Linux 内核自身的编译任务时，编译时间也缩短了几个百分点。
4. 4. 更低的内存占用：虽然引入了更复杂的表结构，但由于清理了大量重复的冗余代码，系统在空闲时的内存占用反而有所下降。

最关键的一点是，这种新架构是“面向未来”的。它让 Swap 分区能够更灵活地进行动态分配和增长而不是死板的固定块管理。

基于真实需求

腾讯之所以如此积极地推动这项改进，核心动力源于其庞大的云服务基础设施。

在公有云环境中，成千上万个容器运行在同一台宿主机上。为了提高资源利用率，超卖内存是行业惯例。当数百个容器同时面临内存压力时，内核的 Swap 处理能力直接决定了系统的稳定性。

以前，由于 Swap 路径上的锁争抢，系统可能会进入一种“伪死机”状态：CPU 并不忙，但都在等锁，硬盘 IO 也跑不满，导致业务请求堆积，最终引发雪崩。腾讯的这套优化，说白了就是把这个窄瓶颈扩宽，让内存回收的过程更加顺滑。

社区的反应

目前，这套补丁正处于社区的密集审阅阶段。Linux 内核内存管理领域的维护者对这种大范围的重构持谨慎但欢迎的态度。

从 2025 年 8 月发布的第一个原型版本，到 2026 年 1 月现在的最新迭代，Kairui Song一直在根据社区反馈微调代码。补丁中明确提到，目前的改动只是第一阶段，后续还将针对交换分配器进行更深层次的解耦。

对于普通用户来说，这些改动在 2026 年的中后续内核版本（如 Linux 7.0 或更高的补丁版本）中可能会变为默认行为。届时，无论是运行在服务器上的数据库，还是开启了大量网页标签的桌面系统，都能在内存吃紧时获得更流畅的体验。

补充：

此次更新还特别针对 mTHP进行了优化。在过去，如果 Swap 分区出现碎片，内核很难找到连续的存储空间来存放一个大页，只能强行拆分成 4K 的小页，这不仅增加了 IO 次数，还损失了性能。新的交换表结构能够更好地感知集群分配，尽可能保持大页的完整性。

Linux 调度器和内存管理系统的每一次微调，都是在吞吐量与延迟之间寻找新的平衡。腾讯这次对 Swap 的重构，无疑是向“高并发、高性能”方向的又一次努力。