告别 SLAB 复杂锁争用？Linux 7.0 拟全面铺开 Sheaves 机制

Linux 内核的内存管理子系统又要搞大动作了。根据 Phoronix 在 2026 年 1 月 31 日的最新报道，随着 Linux 7.0 开发周期的临近，内核开发者正在筹备一项重大的底层变革：用 Sheaves 机制全面取代现有的 CPU 局部 Slab 缓存代码。

这项改动不仅为了性能，更是为了甩掉长久以来困扰实时内核（PREEMPT_RT）的复杂锁竞争包袱。

在此之前，Sheaves 机制其实已经在 Linux 6.18 中低调登场，但当时它只是作为一个“可选项”存在的。

SUSE 的工程师、SLAB 子系统维护者 Vlastimil Babka 当时的设想是先让大家试用，最终目标是将所有的内存缓存都迁移到这套新机制上。

现在，时机似乎成熟了，Vlastimil Babka 已经将相关补丁提交到了 slab/for-next 分支，如果不出意外，这套机制将在 Linux 6.20 到 7.0 的合并窗口期间正式上位。

为什么要换？旧的 Slab 有什么问题？

要理解这个改动的分量，得先看看我们现在的内核是怎么分配内存的。在现有的 SLUB 分配器（Linux 目前默认的 Slab 分配器）中，为了提高性能，内核会给每个 CPU 维护一个“局部缓存”（per-cpu partial slabs）。

这听起来很美好，CPU 需要小块内存时，直接从自己兜里掏就行，不用去跟别的 CPU 抢全局锁。

但问题出在“无锁”实现的细节上。为了保证数据一致性，现有的实现大量使用了 this_cpu_try_cmpxchg128/64 这种原子操作指令。这在普通场景下还能应付，可一旦涉及到 PREEMPT_RT（实时抢占）或者 kmalloc_nolock() 这种极端场景，代码复杂度就呈指数级上升。

原子操作虽然没有传统的锁那么重，但在高并发下依然会导致 CPU 之间的总线争用，而且一旦失败就需要不断重试，不仅代码写起来像在走钢丝，维护起来更是噩梦。

Vlastimil Babka 直言，现有的这套无锁快速路径（lockless fastpaths）太复杂了。

Sheaves 是什么？

Sheaves（束/捆）这个概念，某种程度上是对更古老的 Bonwick 论文中 "Magazines" 概念的一种致敬和改良。你可以把它想象成给每个 CPU 发了一个私有的“小篮子”。

当内核需要申请内存时，直接从当前 CPU 的这个“束”里拿一个对象出来。重点是：完全不需要锁，也不需要复杂的原子操作重试。

因为这个“束”是当前 CPU 独占的，别的 CPU 根本碰不到。只有当这个“束”空了，或者满了需要回收时，才会去跟全局的“谷仓”（Barn，即每 NUMA 节点的缓存）打交道。

这种设计的核心在于“隔离”。通过引入 Sheaves，内核把内存分配和释放变成了纯粹的本地操作，极大减少了 CPU 之间为了争抢内存元数据而产生的通信开销。

Linux 7.0 的野心

在即将到来的 Linux 7.0（或者 6.20+）更新中，Sheaves 将不再是可选项，而是计划替换掉除了两个引导阶段必须的缓存之外的所有 CPU 缓存。这意味着，那堆让开发者头大的、基于 cmpxchg 的复杂代码将被移除。

不过，Vlastimil 也保留了一点“求生欲”。他提到，虽然大部分场景下的无锁操作被移除了，但在处理跨 NUMA 节点释放对象时，某种形式的无锁更新（lockless freelist update）依然被保留了下来。这是为了避免在跨节点操作时必须获取全局锁，防止性能回退。

目前这套补丁已经经历了四次迭代（v4），正排队等待合并。虽然 Vlastimil Babka 在邮件列表中比较谨慎地使用了“希望能提升性能”（hopefully improved performance）这种措辞，并没有甩出具体的跑分数据，但从原理上分析，减少原子操作和锁争用，在高核心数的现代服务器上理论上会有明显的收益。

写在最后

对于普通用户来说，Linux 7.0 的这项改动可能感知不强，反正系统跑起来还是那个样。但对于那些在服务器上跑高并发业务、或者对实时性有苛刻要求的场景，Sheaves 的转正可能是一个值得期待的优化。

长久以来，Linux 内存管理一直在“极致性能”和“代码可维护性”之间走钢丝。Sheaves 的出现，似乎暗示着内核社区正在尝试用一种更清晰的数据结构设计，来解决日益复杂的并发问题，而不是死磕那些晦涩的原子指令。

这套代码预计将在二月份正式提交，届时我们就能看到它在真实生产环境下的表现了。

信息来源：

• • Phoronix: Linux 7.0 Aims To Replace More Caching Code With Sheaves
• • LKML (Linux Kernel Mailing List) regarding slab/sheaves patches.