🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

在 Linux 内核开发中，内存分配的性能优化一直是核心议题。当我们在用户态调用malloc()或在内核中使用kmalloc()时，最终都会触及到内核的 slab 分配器。这个负责小内存块管理的子系统，其性能的细微提升，都可能对系统整体吞吐量产生显著影响。近期，Linux 内核社区在 7.2 版本中引入了一项针对 slab 分配器的重要重构：延迟构建 freelist。这项改动号称在某些场景下能将分配性能提升高达 70%。这并非简单的参数调优，而是一次触及 slab 核心数据结构和分配路径的底层重构。本文将深入剖析这项优化的背景、原理、实现细节，并探讨其对开发者的实际影响。

1. 背景与核心概念：为什么需要 slab 分配器？

在深入探讨优化之前，我们必须先理解 slab 分配器存在的意义。Linux 内核的内存管理是一个层次化的体系，最底层是物理页帧的伙伴系统（Buddy System），它负责以页（通常为 4KB）为单位管理物理内存。然而，内核中大量数据结构（如task_struct,inode,dentry）的大小远小于一页。如果每次分配一个几十字节的结构体都向伙伴系统申请一整页，将造成严重的内存碎片和巨大的性能开销。

slab 分配器正是为了解决这个问题而诞生的。它的核心思想是对象缓存和预分配。slab 会预先从伙伴系统申请一个或多个连续的物理页，并将其划分为一个个大小相等的“对象”（object）。这些对象被组织成链表（freelist），当内核需要分配特定大小的内存时，直接从对应的 slab 缓存中获取一个空闲对象，释放时也只需将其归还到 freelist 中，避免了频繁地向伙伴系统申请/释放页面。

1.1 slab 的三种实现：slab, slub, slob

历史上，Linux 内核有三种 slab 实现：

• slab: 最早的实现，设计复杂，管理开销大，对 NUMA 支持繁琐。
• slub: 在 2.6.22 中引入，是 slab 的简化版（Unqueued slab allocator）。它移除了复杂的队列，优化了 NUMA 支持，成为目前服务器和桌面系统的默认选择。
• slob: 为嵌入式小内存系统设计，极其精简。

本文讨论的优化主要针对目前主流的slub实现。当我们谈论“slab”时，在当代 Linux 语境下，通常指的就是 slub。

1.2 slab 的核心数据结构与快速路径

slub 的核心管理结构是kmem_cache，它为每一种特定大小的对象（如task_struct）维护一个缓存。每个 CPU 都有一个本地的kmem_cache_cpu结构，其中缓存着一个活跃的 slab（page指针）和一个指向该 slab 中第一个空闲对象的freelist指针。

快速分配路径（fast path）是性能的关键：当某个 CPU 需要分配对象时，它首先检查自己的kmem_cache_cpu->freelist。如果freelist不为空，只需简单的指针操作即可完成分配，全程无锁。这个路径的速度直接决定了高频小内存分配的性能。

// 简化的快速路径分配逻辑（概念示意） void *kmem_cache_alloc(struct kmem_cache *s, gfp_t gfpflags) { struct kmem_cache_cpu *c; void *object; // 1. 获取当前CPU的本地缓存 c = this_cpu_ptr(s->cpu_slab); // 2. 检查freelist（快速路径） object = c->freelist; if (likely(object)) { // 3. 更新freelist指向下一个空闲对象 c->freelist = get_freepointer(s, object); c->tid = next_tid(c->tid); return object; } // 4. 如果freelist为空，则进入慢速路径（slow path） return __slab_alloc(s, gfpflags, _RET_IP_); }

问题的核心就在于这个freelist。在优化之前，当一个 slab 被初始化或从伙伴系统分配出来时，内核会立即遍历这个 slab 中的所有对象，构建一个完整的空闲对象链表（freelist）。这个“初始化时构建 freelist”的操作，就是本次优化所要改变的目标。

2. 问题根源：初始化构建 freelist 的开销

让我们设想一个典型的场景：内核创建一个新的kmem_cache用于管理某种对象（例如大小为 256 字节的对象）。当向伙伴系统申请到一个新的 slab（比如一个 4KB 的页）后，传统做法会立即执行以下步骤：

1. 计算对象数量：根据对象大小和页面大小，计算该 slab 可以容纳多少个对象（例如，4KB / 256B ≈ 16个，需考虑对齐开销）。
2. 遍历并链接：从 slab 的起始地址开始，以对象大小为步长遍历每个潜在的对象位置，将每个对象的“freepointer”区域设置为下一个对象的地址，从而形成一个单链表。
3. 设置头指针：将 slab 的page->freelist指向链表头（第一个对象），并将kmem_cache_cpu->freelist也指向它。

这个过程在 slab 创建时发生。如果系统中有成百上千个 slab（这在长期运行的服务器中很常见），并且对象尺寸很小（导致每个 slab 中对象数量很多），那么初始化所有 freelist 的总开销就不可忽视。更重要的是，这些预先构建的 freelist 可能根本用不上。例如：

• 一个 slab 可能被分配后，只使用了其中少数几个对象，随后就因为进程退出等原因被整体释放回伙伴系统。
• 在系统启动初期或内存压力较大时，大量 slab 被创建以备不时之需，但实际负载可能只使用了其中一小部分。

关键洞察：预先构建 freelist 是一种“预支”的成本，它假设 slab 会被充分使用。但在很多情况下，这是一种浪费。延迟构建 freelist 的核心思想就是将这部分成本从“初始化时”转移到“第一次分配时”，实现按需构建。

3. 解决方案：延迟构建 freelist 的设计与实现

Linux 7.2 的优化 patch 的核心是引入了一种新的 slab 状态和相应的处理逻辑。我们不再在allocate_slab()（从伙伴系统获取页面并初始化 slab 的函数）中构建完整的 freelist。

3.1 新的 slab 状态：DEACTIVATED_TO_FULL

在传统的 slub 实现中，slab 主要有以下几种状态，通过page->freelist和page->inuse等字段来体现：

• Empty:freelist有值，inuse == 0。所有对象都空闲。
• Partial:freelist有值，0 < inuse < objects。部分对象被分配。
• Full:freelist = NULL,inuse == objects。所有对象都被分配。

新的优化引入了一个过渡状态。当一个 slab 被分配出来但尚未构建 freelist 时，它被标记为一个特殊状态。在内核代码中，这通常通过将page->freelist设置为一个特定的、非空且不是有效对象指针的值来实现（例如(void *)0xDEADBEEF或利用page结构的其他字段组合），我们可以将其概念化为DEACTIVATED_TO_FULL。这个状态表示：“这是一个全新的 slab，它的 freelist 还未初始化，但逻辑上它所有的对象都是可分配的（即‘满’的，因为没有一个被正式分配出去）”。

3.2 修改后的分配路径

分配逻辑需要适应这种新的状态。以下是修改后的快速路径和慢速路径的协同工作流程：

场景一：首次从新 slab 分配（触发 freelist 构建）

1. CPU 本地缓存c->freelist为空，需要从慢速路径获取新 slab。
2. 慢速路径__slab_alloc发现一个处于DEACTIVATED_TO_FULL状态的 slab。
3. 此时，而不是直接返回一个对象，内核会调用一个新的辅助函数（例如build_freelist_for_new_slab()）。
4. 该函数现场遍历这个 slab，构建 freelist 链表，并将page->freelist设置为链表的头节点。
5. 同时，它将 slab 的状态从DEACTIVATED_TO_FULL转变为正常的Partial状态（因为即将分配出一个对象，inuse从 0 变为 1）。
6. 从刚构建好的 freelist 中取出头节点对象返回给调用者，并将c->freelist更新为链表中的下一个对象。

场景二：从已有 freelist 的 slab 分配（常规路径）这与优化前完全一致，性能无损。一旦 freelist 被构建，后续对该 slab 内对象的分配和释放都走高效的指针操作。

3.3 关键的数据结构改动

为了支持延迟构建，主要改动集中在 slab 页面 (struct page) 的状态识别和kmem_cache的操作函数上。虽然内核源码中的具体标识可能因版本和配置略有不同，但其思想是通用的。关键点在于，page->freelist不再只有NULL（Full）或有效指针（Partial/Empty）两种状态，而是增加了一个特殊的标记值。

// 概念性代码，说明如何检查和处理延迟构建的slab static void *get_object_from_new_slab(struct kmem_cache *s, struct page *page, int node) { void *object; // 检查是否是未初始化freelist的新slab if (unlikely(page->freelist == SPECIAL_DEACTIVATED_MARKER)) { // 延迟构建freelist！ build_freelist(s, page); // 现在page->freelist已经指向一个有效的链表头 // 将slab加入到CPU本地缓存或NUMA节点的partial列表 ... } // 现在可以像普通slab一样分配 object = page->freelist; page->freelist = get_freepointer(s, object); page->inuse++; return object; }

build_freelist函数就是原来在allocate_slab中执行的遍历和链接操作，现在被延迟到真正需要时执行。

4. 性能收益分析：为什么能快 70%？

“最高快 70%” 这个数字听起来很惊人，但它是有特定场景的。性能提升主要来自以下几个方面，而非所有分配操作都加速 70%。

4.1 降低冷启动和内存压力下的开销

这是收益最明显的场景。考虑以下情况：

• 系统启动：大量内核子系统初始化，创建众多kmem_cache并预分配 slab。延迟构建避免了初始化所有 freelist 的 CPU 周期和缓存污染，加速启动过程。
• 突发内存申请：某个应用程序突然开始大量分配某种对象，导致内核需要创建大量新 slab。延迟构建确保只为实际被分配的对象支付 freelist 构建成本。
• 内存回收后：当内存紧张，kswapd 回收了很多 empty slab 后，系统负载下降，这些 slab 又被释放。当负载再次上升时，这些 slab 被重新分配，如果采用旧模式，又会经历一次无用的 freelist 初始化。新模式则避免了这次开销。

在这些场景下，节省的总时间 ≈ (未使用的对象数量) × (构建每个链表节点的开销)。对于对象很小、每个 slab 包含对象很多（如kmalloc-96）的缓存，节省的比例可以非常高，从而在宏观基准测试（如反复创建销毁大量进程或文件句柄）中观察到显著的吞吐量提升。

4.2 改善缓存局部性（Cache Locality）

CPU 缓存的速度远快于内存。旧模式中，build_freelist会顺序访问 slab 中每一个对象的内存地址以设置其 freepointer。如果 slab 很大（例如由多个页组成），这个操作会污染 CPU 的数据缓存（D-Cache），将可能很快就要用到的其他有用数据挤出去。 新模式将构建操作分散到多次分配请求中。当第一次分配触发构建时，它构建的 freelist 节点（即对象本身）很可能立即被使用。这意味着构建链表时加载到缓存的数据（对象内存）没有被浪费，紧接着就被访问了，提高了缓存命中率。

4.3 对快速路径（Fast Path）的影响

这是最需要澄清的一点：延迟构建 freelist 并没有优化快速路径本身。一次成功的c->freelist非空分配，其指令路径和速度与之前完全相同。 它的优化在于：

1. 减少了慢速路径（Slow Path）的负担：在需要获取新 slab 时，allocate_slab函数更快返回，因为它跳过了构建 freelist 的循环。
2. 将构建开销分摊并隐藏：将一次性的、集中的开销，分摊到多次分配请求中，并且与对象的使用更紧密地耦合，从系统响应性的角度看更平滑。

因此，对于已经处于活跃状态、freelist 已构建的 slab，其分配性能不变。优化主要体现在 slab 的“初始化”和“首次使用”阶段。

5. 潜在影响与注意事项

任何底层优化都有其权衡。延迟构建 freelist 也不例外。

5.1 内存诊断工具（如slabtop,/proc/slabinfo）

/proc/slabinfo中的active_objs（活跃对象数）和num_objs（总对象数）的统计逻辑可能需要调整。在旧模型中，一个 slab 一旦分配，其num_objs就固定了。在新模型中，一个DEACTIVATED_TO_FULL状态的 slab，其对象在 freelist 构建前是否应被计入num_objs？内核的实现必须确保这些统计信息依然准确，不影响监控。开发者需要知道，在查看这些信息时，新分配的、未使用的 slab 可能不会立即贡献其全部对象到统计中。

5.2 调试特性（如SLAB_POISON,SLAB_RED_ZONE）

slub 具有强大的调试功能，例如SLAB_POISON（用特定字节填充对象，检测未初始化使用）和SLAB_RED_ZONE（在对象周围插入警戒区，检测缓冲区溢出）。这些功能通常在对象分配时（slab_alloc）和释放时（slab_free）进行操作。 延迟构建 freelist 时，构建操作（build_freelist）本身也需要正确处理这些调试标志。例如，在构建链表时，是否要对对象内存进行“毒化”？这需要仔细设计，确保调试功能在延迟构建场景下依然有效，不会引入新的问题或漏报。

5.3 对实时性（Real-Time）的潜在影响

对于实时性要求极高的内核，延迟构建引入了一个不确定性：第一次从新 slab 分配对象时，会有一个额外的、可变时间的构建开销。在旧模型中，这个开销发生在 slab 创建时，可能是在非关键路径或初始化阶段。在新模型中，它可能发生在关键的任务分配路径上。 虽然对于大多数通用服务器和桌面系统，这个额外开销微乎其微（只是一次简单的内存遍历），并且被分摊后影响更小，但对于硬实时（Hard Real-Time）内核，任何在关键路径上增加的可变延迟都需要仔细评估。社区在合并此类 patch 时，通常会进行广泛的性能基准测试和回归测试，以确保对主流用例利大于弊。

6. 如何验证与观察此优化

如果你想在自己的系统或内核开发中验证和感受这一优化，可以尝试以下方法：

6.1 查看内核版本与配置

首先确认你的内核版本 >= 7.2，并且使用的是 slub 分配器（默认）。

uname -r cat /boot/config-$(uname -r) | grep CONFIG_SLUB

6.2 使用 ftrace 或 perf 进行跟踪

你可以使用内核的跟踪工具来观察 slab 分配函数的耗时变化。重点比较allocate_slab和__slab_alloc中 freelist 构建相关部分的耗时。

# 使用 perf 记录 slab 分配相关的事件（示例） perf record -e kmem:kmem_cache_alloc -e kmem:kmem_cache_alloc_node -ag perf report

通过对比优化前后内核的 profile 数据，可以看到allocate_slab函数占用 CPU 时间的减少，以及可能出现的新的构建函数（如build_freelist）的耗时。

6.3 编写微基准测试（Micro-benchmark）

创建一个内核模块，反复分配和释放特定kmem_cache中的对象，并测量吞吐量（操作/秒）。在以下两种模式下测试：

1. 预热后测试：先分配释放大量对象，让系统进入稳定状态（所有 slab 的 freelist 已构建），然后测量性能。这代表优化后的快速路径，理论上应与之前持平。
2. 冷启动测试：在每次测试迭代前，清空对应的kmem_cache（这需要特殊方法或重启模块），然后测量从零开始分配对象的性能。这应该能体现出优化带来的提升。

6.4 监控/proc/slabinfo的变化

在运行一个周期性创建销毁大量对象（如短生命周期进程）的负载时，观察特定缓存（如task_struct）的active_objs和num_objs的增长关系。在优化前，num_objs可能会随着新 slab 的创建而阶梯式跳增。在优化后，num_objs的增长可能会更紧密地跟随active_objs，反映出“按需构建”的特性。

7. 总结与最佳实践

Linux 7.2 中 slab 分配器延迟构建 freelist 的优化，是一个经典的“按需计算”思想在系统内核中的应用。它通过将初始化成本从 slab 创建时转移至首次对象分配时，显著提升了内存子系统在冷启动、突发负载和内存回收再分配场景下的性能。

对开发者的启示：

1. 理解内存分配成本不是均等的：kmalloc/kfree的成本高度依赖于其所处的上下文——是命中 CPU 本地缓存的快速路径，还是需要触及 NUMA 节点甚至伙伴系统的慢速路径。本次优化再次提醒我们，慢速路径的优化同样重要。
2. 关注数据结构的初始化开销：内核的这种优化模式可以借鉴到用户空间编程中。对于池化（pooling）或缓存（caching）机制，考虑是否所有资源都需要在池创建时完全初始化？能否将初始化延迟到第一次使用时？
3. 性能优化需要精准测量：70% 的提升是在特定基准测试下得出的。在你的实际应用中，收益可能不同。任何性能优化都应以实际 profiling 数据为指导。
4. 保持对底层变化的关注：内核的持续演进会改变其性能特征。作为系统开发者或运维，了解像 slub 分配器这样的核心子系统的重大改动，有助于你更好地解释系统性能指标，进行容量规划和故障排查。

这项优化是 Linux 内核社区持续打磨核心子系统的一个优秀范例。它没有增加复杂性，而是通过更智能地安排现有操作的时间点，就收获了显著的性能回报。随着 Linux 在从数据中心到边缘计算的各个领域持续部署，此类低层级、高效率的优化将继续发挥至关重要的作用。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度