深入解析 Linux 6.6 内核默认 SLUB 对象分配器原理与实战

引言：为什么需要对象分配器？

想象一下这个场景：内核每秒都要创建和销毁成千上万个 task_struct（进程描述符）、inode（文件索引节点）这类小对象。如果每次分配内存都直接向底层的页面分配器（Page Allocator）请求一个或多个完整的物理页（通常是4KB），马上就会引发两个棘手的问题：

1. 外部碎片：频繁分配和释放不同大小的对象，会导致物理内存中出现大量无法被利用的小空洞。
2. 性能开销：每次调用页面分配器都是一次昂贵的操作，涉及复杂的伙伴系统算法和锁竞争。

为了解决这两个核心问题，Linux 内核引入了对象分配器（Object Allocator），它更常被称为 Slab 分配器。它作为页面分配器之上的一层，专门为频繁分配/释放的、大小固定的小对象提供高效、低碎片的内存管理服务。

一、模块概述

对象分配器的核心思想可以概括为“批发零售”和“缓存复用”。

• 批发：当某种类型的对象（例如 task_struct）首次被请求时，分配器会向页面分配器“批发”一整块连续的物理页，这块内存被称为一个 slab。
• 零售：这块 slab 会被精确地划分为多个大小固定的槽位，用于存放该类型的对象。当内核需要一个新对象时，分配器只需从 slab 中“零售”一个空闲槽位即可，速度非常快。
• 缓存复用：当对象被释放时，它并不会立刻归还给底层的页面分配器，而是被放回其所属 slab 的空闲列表中。下次再分配同类型对象时，可以直接复用这个刚释放的槽位，既省去了初始化的开销，又避免了内存碎片。

1.1 核心文件列表

Linux 内核历史上存在三种不同的对象分配器实现，它们在代码库中共存，但在编译时只能选择一种。

• slab.c (CONFIG_SLAB): 这是最原始的 Slab 分配器，由 Jeff Bonwick 为 Solaris 设计并引入 Linux。它功能强大，调试选项丰富，但数据结构和算法相对复杂。
• slub.c (CONFIG_SLUB): 这是当前 Linux 内核（包括 6.6 版本）的默认分配器。它的设计哲学是“简化”。SLUB 去掉了 SLAB 中许多复杂的特性（如 per-CPU 的完整缓存数组、复杂的着色机制），转而依赖更简单的 per-CPU 单链表和强大的页面级操作，从而获得了更好的性能和更低的内存开销。
• slob.c (CONFIG_SLOB): 这是一个极度简化的分配器，专为内存资源极其有限的嵌入式系统设计。它本质上就是一个基于双向链表的 First-Fit 分配器，会产生碎片，但在小内存场景下代码尺寸最小。
• slab_common.c: 这个文件包含了所有分配器共用的通用代码，例如 kmalloc/kfree 的前端接口、通用的 cache 创建/销毁逻辑等。
• mempool.c: 内存池（Memory Pool）是一种特殊的分配机制，它预先保留一定数量的对象，在系统内存压力极大、普通分配可能失败时，仍能保证关键路径的内存分配成功。

1.2 三种分配器对比

特性	SLOB	SLAB	SLUB
复杂度	最简单	复杂	中等
内存开销	最小	较大	中等
性能	较慢	较好	最好
调试功能	弱	强	中等
适用场景	极小嵌入式系统	需要强大调试的历史系统	高性能通用系统（默认）

结论：对于绝大多数现代 Linux 系统，SLUB 是最佳选择。它在性能、内存效率和代码简洁性之间取得了优秀的平衡。

1.3 内部头文件 (mm/slab.h)

这个头文件定义了分配器内部使用的关键数据结构。一个巧妙的设计是，为了节省内存，Linux 内核巧妙地复用了 struct page 结构体来表示一个 slab。

• 当一个 page 结构体的 PG_slab 标志位被设置时，它就不再代表一个普通的内存页，而是代表一个 slab。
• 在 struct slab 的联合体定义中，我们可以看到 SLAB 和 SLUB 各自特有的字段。这体现了内核代码的精妙设计：同一块内存，根据配置选项的不同，被解释为不同的结构。

二、基本原理

2.1 为什么需要 Slab 分配器

核心驱动力是解决碎片和性能问题。除此之外，Slab 分配器还提供了几个高级特性：

• 批量分配：一次向页面分配器申请多个页，减少系统调用次数。
• 对象缓存：释放的对象不立即归还，形成缓存，供下次快速分配。
• 构造/析构函数：可以为特定类型的对象注册初始化（ctor）和清理（dtor）函数。当对象第一次被分配或最终被销毁时，这些函数会被自动调用。
• 对象着色 (Object Coloring)：这是 SLAB 的一个经典优化。CPU 缓存通常以缓存行（Cache Line）为单位进行映射。如果所有 slab 中的对象都从同一个地址偏移开始，那么它们可能会映射到同一个缓存行集合（Set），导致频繁的缓存冲突（Cache Thrashing）。通过为不同的 slab 设置不同的初始偏移（着色），可以让对象分散到不同的缓存行集合中，从而提高缓存命中率。

2.2 核心概念

理解 Slab 分配器，必须掌握三个核心概念：kmem_cache, slab, 和 object。

• 2.2.1 kmem_cache（缓存）

  • 角色：这是分配器的核心。每一种需要被 Slab 管理的对象类型，都有且仅有一个对应的 kmem_cache。你可以把它想象成一个“对象工厂”。
  • 内容：kmem_cache 结构体包含了管理该类型对象所需的所有元信息：
    • object_size: 对象的实际大小。
    • align: 对齐要求。
    • objects: 每个 slab 可以容纳多少个对象。
    • ctor/dtor: 构造和析构函数指针。
    • cpu_slab: Per-CPU 缓存，这是 SLUB 实现高性能的关键。每个 CPU 核心都拥有自己私有的、无锁的空闲对象列表，极大地减少了多核竞争。
    • node[]: Per-NUMA Node 缓存。在 NUMA 系统中，每个内存节点（Node）维护一个 partial slab 链表，用于在 Per-CPU 缓存耗尽时提供后备对象。

• 2.2.2 slab（页面集合）

  • 角色：slab 是 kmem_cache 用来存储实际对象的物理容器。它由一个或多个连续的物理页组成。
  • 结构：在 SLUB 中，slab 的元数据（如 freelist 空闲指针、inuse 已用对象数等）直接嵌入在 struct page 中。对象本身则紧随其后存储在页内存里。

• 2.2.3 对象着色

  • 目的：如前所述，是为了优化 CPU 缓存性能。
  • SLAB vs SLUB：SLAB 实现了复杂的着色机制。而 SLUB 认为现代处理器的缓存足够大，这种优化带来的收益有限，反而增加了复杂性，因此在默认情况下没有实现复杂的着色，而是采用了更简单的策略。

2.3 SLUB vs SLAB 架构差异

这是理解现代内核内存管理的关键。

• Per-CPU 缓存：

  • SLAB: 使用一个名为 array_cache 的数组来缓存一批空闲对象。分配和释放都在这个数组上操作，当数组满或空时，才去和 node 层交互。
  • SLUB: 使用一个简单的单链表（freelist）。分配就是从链表头取一个对象，释放就是把对象插到链表头。这种 LIFO（后进先出）的方式非常高效，并且利用了 CPU 缓存的局部性原理（最近释放的对象很可能还在缓存里）。

• Slab 链表：

  • SLAB: 维护三个独立的链表：slabs_full（完全用满的 slab）、slabs_partial（部分使用的 slab）、slabs_free（完全空闲的 slab）。
  • SLUB: 只维护一个 partial 链表。完全空闲的 slab 会被立刻释放回页面分配器（除非有特殊要求），完全用满的 slab 则不需要被链表跟踪，因为没有空闲对象可分配。这种简化大大减少了管理开销。

• 对象查找：

  • SLAB: 需要通过对象地址计算其在 slab 中的位置，过程稍显复杂。
  • SLUB: 由于 struct page 直接代表 slab，通过 virt_to_head_page() 函数可以一步到位地从任意对象地址找到其所属的 slab（即 page 结构），效率极高。

三、核心函数调用关系

3.1 kmalloc/kfree 流程

这是操作系统中最常用的动态内存分配接口。

• kmalloc:

  1. 用户调用 kmalloc(size, flags)。
  2. 内联函数根据 size 查找预定义好的 kmalloc_caches[] 数组，找到最合适（大于等于所需大小）的 kmem_cache。
  3. 调用 slab_alloc() 进入分配流程。
  4. 快速路径：尝试从当前 CPU 的 kmem_cache_cpu->freelist 中获取一个对象。如果成功，整个过程无锁、极快。
  5. 慢速路径：如果 Per-CPU 缓存为空，则进入 __slab_alloc()。它会从当前 NUMA Node 的 partial 链表中取出一个 slab，将其设置为当前 CPU 的活动 slab，并填充 Per-CPU 的 freelist。
  6. 如果 Node 的 partial 链表也为空，则调用 new_slab() 向页面分配器申请新的物理页来创建一个新的 slab。

• kfree:

  1. 用户调用 kfree(ptr)。
  2. 通过 virt_to_head_page(ptr) 找到对象所属的 slab（page）。
  3. 从 page->slab_cache 找到对应的 kmem_cache。
  4. 调用 slab_free()。
  5. 快速路径：直接将对象插入到当前 CPU 的 freelist 链表头。
  6. 慢速路径：如果释放的对象不属于当前 CPU 的活动 slab，或者 Per-CPU 缓存过长需要回收，则进入 __slab_free()。它会获取 Node 的自旋锁，将对象放回其所属 slab 的 freelist 中。如果该 slab 因此变为空闲，且系统中有过多的 partial slab，这个空闲 slab 就会被释放回页面分配器。

3.2 kmem_cache 创建/销毁流程

• 创建 (kmem_cache_create):

  1. 内核子系统（如 VFS、Scheduler）调用此函数，声明自己需要管理一种新类型的对象。
  2. 分配器会计算最优的 slab 布局（每个 slab 放多少对象，对齐方式等）。
  3. 为这个新的 cache 分配一个 kmem_cache 结构体本身（这通常也是通过 kmalloc 完成的，形成了一个自举过程）。
  4. 初始化其 Per-CPU 和 Per-Node 数据结构。
  5. 返回一个指向该 cache 的指针，供后续 kmem_cache_alloc/free 使用。

• 销毁 (kmem_cache_destroy):

  1. 当一个内核子系统卸载时，需要销毁其创建的 cache。
  2. 分配器会等待，直到该 cache 管理的所有对象都被释放（引用计数为0）。
  3. 遍历并释放所有与该 cache 关联的 slab 页面。
  4. 最后，释放 kmem_cache 结构体本身。

四、SLUB 分配器详解

作为当前的主流实现，我们深入剖析一下 SLUB。

4.1 SLUB 核心数据结构

• kmem_cache: 如前所述，它是对象工厂。
• kmem_cache_cpu: Per-CPU 缓存的核心。freelist 是一个指向下一个空闲对象的指针，page 指向当前正在使用的 slab。这种设计使得快速路径的分配/释放操作只需要修改这两个字段，无需任何锁。
• kmem_cache_node: Per-Node 的后备仓库。它主要维护一个 partial 链表，里面存放着那些还有空闲对象、但未被任何 CPU 作为活动 slab 使用的 slab。

4.2 & 4.3 对象分配/释放流程

这部分在 3.1 中已有详细描述。SLUB 的精髓就在于其极简的快速路径和高效的慢速路径回退机制。通过 Per-CPU 无锁操作处理绝大多数情况，只有在缓存不命中时才动用带锁的全局资源（Node 链表），从而实现了卓越的可扩展性。

4.4 对象构造/析构

构造函数 (ctor) 在 slab 创建时被调用，用于初始化 slab 中的每一个对象。这对于需要复杂初始化的对象非常有用。析构函数 (dtor) 在对象最终被销毁（即其所在的 slab 被释放回页面分配器时）被调用。注意，kfree 并不会触发析构函数。

五、SLAB 分配器详解

虽然不再是默认选项，但了解 SLAB 有助于理解历史代码和其设计思想。其核心区别在于更复杂的 Per-CPU array_cache 和三个 slab 链表的管理。array_cache 作为一个缓冲区，可以批量地从 node 层获取或返还对象，旨在减少与 node 层的交互频率。然而，这种复杂性在现代多核系统中反而可能成为瓶颈。

六、通用函数

6.1 kmalloc/kfree

这是面向“动态大小”的通用接口。Kernel在启动时会预先创建一系列大小固定的 kmem_cache（如 8, 16, 32, ..., 8192 字节等）。kmalloc 的本质就是根据请求的大小，选择一个合适的预建 cache 来分配对象。

6.2 kmem_cache_create/destroy

这是面向“特定类型”的专用接口。当你知道自己的对象大小固定，并且希望获得最佳性能或使用构造函数时，就应该使用这套 API。

七、内存池（mempool）

内存池是分配器之上的又一层保障。它的原理很简单：

• 创建时，预先通过底层分配器（如 kmem_cache_alloc）分配 min_nr 个对象，存放在自己的保留池里。
• 分配时 (mempool_alloc)：
  1. 首先尝试从保留池中分配。这总是成功的。
  2. 如果保留池空了，则直接调用底层分配器的分配函数（如 alloc_fn）。此时可能会失败。
• 释放时 (mempool_free)：
  1. 如果保留池未满，则将对象放回保留池。
  2. 如果保留池已满，则直接调用底层分配器的释放函数（如 free_fn）将其真正释放。

应用场景：I/O 子系统（如 BIO）、网络协议栈等不能容忍分配失败的关键路径。

八、与周边模块的配合

• 页面分配器：对象分配器是页面分配器的直接用户。当需要新的 slab 时，它会调用 alloc_pages()。
• 内存控制组 (cgroup)：现代内核支持对 Slab 内存进行统计和限制。分配和释放时会调用相应的 memcg hook 函数。
• 内存回收 (Reclaim)：当系统内存不足时，vmscan 会调用 shrink_slab()，尝试回收那些长时间未使用的、来自可回收 cache（如 inode, dentry）的空闲对象所占的 slab 页面。
• 设备驱动：驱动程序可以创建带有 GFP_DMA 或 SLAB_DMA 标志的 cache，以确保分配的内存位于 DMA 可访问的区域内。

九、调试与诊断

内核提供了丰富的工具来监控和调试 Slab 分配器：

• /proc/slabinfo: 提供所有 cache 的实时统计信息，是诊断内存泄漏和碎片的首要工具。
• debugfs (/sys/kernel/debug/slab): SLUB 提供了更详细的 debug 信息，甚至支持在线 defrag（碎片整理）。
• Kmemleak: 内核内置的内存泄漏检测工具，可以追踪哪些 kmalloc 的内存从未被 kfree。
• Trace Events: 通过 ftrace 或 perf，可以动态追踪 kmalloc/kfree 等事件，分析性能热点。

十、最佳实践

如何正确、高效地使用对象分配器：

1. 优先使用 kmalloc：对于通用的、动态大小的分配，kmalloc 是首选。
2. 善用 kmem_cache：对于固定大小、高频分配/释放的对象，创建专用 cache 能获得最佳性能。
3. 关键路径用内存池：在绝不允许分配失败的代码路径（如中断上下文、持有重要锁时），使用 mempool。
4. 注意 GFP 标志：在原子上下文（不能睡眠）必须使用 GFP_ATOMIC，而非 GFP_KERNEL。
5. 避免常见错误：如忘记释放、重复释放、释放野指针等。

十一、总结

Linux 内核的对象分配器（特别是 SLUB）是一个精妙的工程杰作。它通过分层缓存（Per-CPU -> Per-Node -> Page Allocator）、对象复用和简化设计，在保证高性能的同时，有效管理了小对象内存的碎片问题。理解其工作原理，对于进行内核开发、性能调优和故障诊断都至关重要。

希望这篇关于 Linux 内核对象分配器的解析能帮助你更深入地理解其运作机制。如果你对更底层的操作系统原理或内核开发有持续的兴趣，可以关注云栈社区，那里有更多深入的技术讨论和资源分享。