Linux 内核 Slab 分配器深度实战：三层架构、性能优化与生产调优全指南

Linux 内核 Slab 分配器是现代操作系统中最经典的小内存分配器设计之一，从 2.1.23 内核版本引入至今，经历了从 Jeff Bonwick 原始 Slab、到 SLUB（Unqueued Slab）、再到当前默认 SLUB 分配器的演进历程。本文将从架构原理、源码实现、API 使用、性能调优和生产陷阱等维度，全面深度拆解这一内核核心子系统。

一、为什么需要 Slab 分配器？

在没有 Slab 分配器之前，内核使用伙伴系统（Buddy System）管理物理内存页。伙伴系统以页（通常 4KB）为最小分配单元，但内核中大量对象大小只有几十到几百字节（如 task_struct 约 7KB、inode 约 700B、dentry 约 192B）。直接通过伙伴系统分配会导致严重的内部碎片问题。

此外，内核对象的创建/销毁频率极高（每秒数万至数百万次），涉及：

• 内存本身分配/释放开销
• 构造函数/析构函数的重复调用（初始化/清理链表指针、引用计数、锁等）
• 频繁的内存分配导致伙伴系统链表操作和空闲页搜索开销

Slab 分配器的核心思想是对象缓存（Object Cache）：预先从伙伴系统申请一整页内存，将其切割为多个相同大小的固定槽位，维护空闲槽位链表，分配/释放仅需链表指针操作，避免了重复初始化和伙伴系统调用。

二、三层缓存架构

Linux 内核内存管理采用严格的三层架构，Slab 分配器位于中间层：

┌─────────────────────────────────────────────────────┐
│           第三层：对象缓存层（Slab Cache）             │
│  kmem_cache: task_struct_cachep, dentry_cache, ...  │
│  管理同类型对象的高速缓存，分配/释放路径最短           │
├─────────────────────────────────────────────────────┤
│           第二层：每CPU节点缓存（per-CPU）            │
│  kmem_cache_cpu: 每个 CPU 的本地 slab 列表           │
│  无锁快速路径，避免 cache line bouncing              │
├─────────────────────────────────────────────────────┤
│           第一层：NUMA 节点缓存（kmem_cache_node）    │
│  每个 NUMA 节点维护 partial/full/empty slab 列表     │
│  跨 CPU 共享，支持 NUMA 亲和分配                     │
├─────────────────────────────────────────────────────┤
│           底层：伙伴系统（Buddy System / zonelists）  │
│  以 page 为单位管理物理内存，为 Slab 分配器提供页框   │
└─────────────────────────────────────────────────────┘

这种层次化设计的优势：

• CPU 热路径完全无锁：从 kmem_cache_cpu 的 freelist 直接取对象，无需任何同步原语
• NUMA 感知：优先从本地 NUMA 节点的空闲列表分配，减少跨节点访问延迟
• 弹性扩缩：当前端压力增大时自动分配新 slab，压力释放后归还空 slab 给伙伴系统

三、核心数据结构详解

3.1 kmem_cache（缓存描述符）

每个 Slab 缓存由 struct kmem_cache 描述，核心字段：

struct kmem_cache {
    struct kmem_cache_cpu __percpu *cpu_slab;   // 每CPU slab缓存（快速路径）
    slab_flags_t              flags;           // 标志位（如 SLAB_ACCOUNT）
    unsigned long             min_partial;       // node 中最少保留的 partial slab 数
    unsigned int              size;             // 对象实际大小（含padding）
    unsigned int              object_size;      // 用户请求的原始对象大小
    unsigned long             offset;           // 空闲对象链表指针的偏移
    unsigned int              oo;               // (min, max) 最优order数
    
    const char               *name;             // 缓存名称（/proc/slabinfo 中使用）
    struct list_head          list;             // 全局缓存链表
    
    struct kmem_cache_node   *node[MAX_NUMNODES]; // NUMA 节点数组
    // ...
};

3.2 kmem_cache_cpu（快速路径核心）

这是 Slab 分配性能的关键所在：

struct kmem_cache_cpu {
    void **freelist;        // 空闲对象链表头指针（LIFO顺序，CPU cache hot）
    unsigned long tid;      // 全局唯一的事务 ID（防止CPU迁移时的双重分配）
    struct page *page;      // 当前正在使用的 slab 页
    struct page *partial;   // 本地CPU的partial slab列表（SLUB特有）
#ifdef CONFIG_SLUB_CPU_PARTIAL
    struct page *freelist_partial;  // CPU partial 列表优化
#endif
};

分配流程：

1. 检查 freelist 是否非空 → 直接弹出首个对象返回（约 10 条指令，无锁）
2. 检查 local partial 列表 → 切换 partial slab 作为当前 slab
3. 检查 kmem_cache_node->partial → 从 Node partial 列表获取
4. 向伙伴系统申请新 slab（new_slab()）

3.3 kmem_cache_node（NUMA 节点层）

struct kmem_cache_node {
    spinlock_t                list_lock;       // 保护 slab 列表的锁
    unsigned long             nr_partial;       // partial slab 数量
    struct list_head          partial;          // partial slab 列表
#ifdef CONFIG_SLUB_DEBUG
    unsigned long             nr_slabs;         // 总 slab 数统计
    unsigned long             total_objects;    // 总对象数统计
    struct list_head          full;             // full slab 列表（调试用）
#endif
};

3.4 slab 内存布局

一个 slab 页的内部结构（以 4KB 页、256B 对象为例）：

┌──────────────────────────────────────┐
│  struct page (slab 元数据)            │ ← page->freelist / page->slab_cache
├──────────────────────────────────────┤
│  slab_slot[0] | slab_slot[1] | ...   │ ← 16 个 256B 对象槽位
│  Slot 0: active object               │
│  Slot 1: active object               │
│  Slot 2: free ─────┐                 │
│  Slot 3: free  ────┤ free pointer    │
│  Slot 4: active    │ chain           │
│  ...               │                 │
│  Slot 15: free ────┘                 │
└──────────────────────────────────────────────────────┘
                    ↓
        freelist = &slot2
        slot[2].next = &slot3
        slot[3].next = &slot15
        slot[15].next = NULL

空闲对象通过将空闲指针直接嵌入对象内存实现，当对象被分配时整个空间存放有效数据，释放时将下一个空闲地址写入。

四、SLUB vs SLAB vs SLOB

Linux 提供了三种 Slab 分配器实现，基于 KConfig 选择：

SLUB 相比 SLAB 的关键改进

• 取消 struct slab 描述符：复用 struct page 结构体的 freelist 和 slab_cache 字段，减少元数据内存开销
• 取消 kmem_bufctl_t 数组：不再维护独立的 bufctl 映射表， freelist 直接嵌入对象
• SMAP 友好的设计：元数据从 slab 端部移至 struct page，减少用户态/内核态边界的暴露面
• CPU partial 列表：每个 CPU 维护独立的 partial 列表，大幅减少 node 锁竞争

五、Slab 分配器 API 详解

5.1 创建与销毁缓存

// 创建自定义缓存（通常放在模块 init 中）
struct kmem_cache *my_cache;
my_cache = kmem_cache_create(
    "my_task_struct",     // 缓存名称（唯一，256字符以内）
    sizeof(my_task_t),    // 对象大小
    0,                    // 对齐要求（0=自然对齐，L1_CACHE_BYTES=缓存行对齐）
    SLAB_HWCACHE_ALIGN | SLAB_ACCOUNT,  // 标志位（硬件缓存对齐 + 内存记账）
    NULL                  // 构造函数（通常为NULL，手动初始化）
);
// 使用 SLAB_HWCACHE_ALIGN 避免 false sharing（高频访问结构体推荐）

// 模块退出时销毁
kmem_cache_destroy(my_cache);

5.2 分配与释放

// GFP 标志说明：
// GFP_KERNEL: 可睡眠，可用于进程上下文
// GFP_ATOMIC: 不可睡眠，可用于中断/软中断上下文
// GFP_NOIO/GFP_NOFS: 限制I/O递归，防止文件系统死锁
// GFP_ACCOUNT: 受 cgroup memory.limit_in_bytes 记账

// 从 slab 缓存分配对象
my_task_t *task = kmem_cache_alloc(my_cache, GFP_KERNEL);
if (!task)
    return -ENOMEM;

// 使用...
task->pid = current->pid;
INIT_LIST_HEAD(&task->list);

// 释放对象给 slab 缓存（不归还给伙伴系统，留在缓存池中）
kmem_cache_free(my_cache, task);

5.3 内置通用缓存（size-N caches）

对于非固定大小对象（如 128B、256B、512B 等），Linux 提供 kmalloc 系列 API，它背后同样使用 Slab 缓存：

// 通用-size slab 缓存原理：
// 预先创建名为 kmalloc-8/16/32/64/128/256/512/1024/2048/4096 的缓存数组
// kmalloc(size, flags) 选择满足 size <= cache_size 的最小缓存

void *buf = kmalloc(1024, GFP_KERNEL);     // 命中 kmalloc-1024 缓存
kfree(buf);

// 大内存分配（>8KB）直接走伙伴系统 + vmalloc 映射
void *big = kvmalloc(128 * 1024, GFP_KERNEL);  // >=128KB用 vmalloc
kvfree(big);

5.4 KMEM_CACHE 宏（固定大小对象的惯用法）

// 最常用模式：定义类型 + 获取缓存指针
static struct kmem_cache *dentry_cache;

// 初始化时创建
dentry_cache = KMEM_CACHE(dentry, SLAB_RECLAIM_ACCOUNT | SLAB_ACCOUNT);
// 等价于：
// kmem_cache_create("dentry", sizeof(struct dentry), 
//     __alignof__(struct dentry), flags, NULL);

// 使用
struct dentry *d = kmem_cache_alloc(dentry_cache, GFP_KERNEL);
if (d) {
    memset(d, 0, sizeof(*d));
    // ...
    kmem_cache_free(dentry_cache, d);
}

六、着色机制（Cache Coloring）

Slab 分配器通过着色（Color Offset）优化硬件缓存利用率：

假设 slab 有 16 个槽位、缓存行 64B，若不调整偏移，不同 slab 中相同索引的对象可能映射到同一 cache line，导致 cache line bouncing。着色通过在每个 slab 起始处添加不同偏移量（0 ~ colour_off 字节），使不同 slab 中同序号对象错开 cache line。

// cache 创建时计算
cachep->colour_off = cache_line_size();    // 通常 64B（L1 cache line）
cachep->colour = cachesize / cachep->colour_off;  // 可用颜色数

在 SLUB 中着色被弱化，因为对象槽位之间有足够的 padding（oo 和 min 控制），且 CPU partial 列表本身就已大幅降低了 false sharing。

七、性能分析与调试

7.1 /proc/slabinfo

最直接的 slab 缓存观测工具：

$ cat /proc/slabinfo | head -20
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
dentry            124356  126780    192   21    1 : tunables  0   0   0 : slabdata     6036   6036    0
inode_cache        89234   91500    656   25    4 : tunables  0   0   0 : slabdata     3660   3660    0
kmalloc-256       38880   40000    256   16    1 : tunables  0   0   0 : slabdata     2500   2500    0
kmalloc-512       13100   13508    512   15    2 : tunables  0   0   0 : slabdata      900    900    0
buffer_head        8088   12540    108   37    1 : tunables  0   0   0 : slabdata      339    339    0
vm_area_struct     7602    8192    208   19    1 : tunables  0   0   0 : slabdata      431    431    0
task_struct        160     248   7936    1    2 : tunables  0   0   0 : slabdata      124    124    0
(mm/zoneinfo 见后)

关键字段解释：

• objsize：对象实际大小（可能略大于 sizeof 因对齐/着色）
• objperslab：每个 slab 页中的对象数
• active_objs/num_objs：使用中/总对象数 → active/num = 利用率，长期偏低说明缓存过大
• active_slabs：已分配 slab 数 → 高 active_slabs + 低 active_objs 说明 slab 分布碎片化（每个 slab 只有很少对象在用）

7.2 slabtop（实时视图）

$ slabtop -o
 Active / Total Objects (% used)    : 287972 / 300496 (95.8%)
 Active / Total Slabs (% used)      : 7016 / 7016 (100.0%)
 Active / Total Caches (% used)     : 123 / 178 (69.1%)
 Active / Total Size (% used)       : 142.53K / 158.22K (90.1%)
 Minimum / Average / Maximum Object : 0.01K / 0.54K / 13.50K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
126780 124356  98%    0.19K   6036       21     48.28K dentry
 91500  89234  97%    0.64K   3660       25     58.56K inode_cache
 40000  38880  97%    0.25K   2500       16     20.00K kmalloc-256

7.3 SLUB_DEBUG（调试利器）strong>

开启 CONFIG_SLUB_DEBUG 和 CONFIG_SLUB_DEBUG_ON 后，Slab 提供强大的运行时检测：

// 内核启动参数
slub_debug=FZPU    // F=启用一致性检查、Z=红区检测、P=中毒填充、U=user tracking

// 针对特定缓存开启/关闭调试
slub_debug=-kmalloc-256  // 关闭 kmalloc-256 的调试（排除干扰）
slub_debug=+inode_cache  // 专门追踪 inode_cache 的分配

SLUB_DEBUG 提供的主要检测：

• Red Zone：在对象末尾哨兵区域，检测越界写
• Poison（0x5a5a5a5a）：释放时填充特定模式，检测 use-after-free
• Owner tracking：记录每个对象的分配/释放调用栈，泄漏排查必备
• Object consistency：分配/释放时校验内部字段，检测双重释放

7.4 slubinfo（slabinfo - 升级版）

// 带追踪信息的 slab 查看
$ slabinfo -r | head
___slab_name-64___:use=2 of 256 (0.0078),free=254
                                   slabs=4 all_obj=1024 free.obj=1020

// 详细追踪每个 slab 页的状态
$ slabinfo dentry -t
Slabcache: dentry   ObjSize: 192   AliSize: 0   Reclaim: no
Objects: 126780 (active 124356, free 2244)
Memory: 23.9 MB total (waste 0. MB)
Slabs: 6036 (partial 6036, full 0)

7.5 ftrace - slub 分配器 tracepoint

// 挂载 debugfs
mount -t debugfs none /sys/kernel/debug

// 开启 slub 分配器追踪
echo 1 > /sys/kernel/debug/tracing/events/kmem/enable

// 查看具体分配调用栈
cat /sys/kernel/debug/tracing/trace_pipe
...
<...>-5120  [003] .... 5987.448980: mm_page_alloc: pfn=1064960 order=0 migrateType=1 gfp_flags=GFP_ZERO
<...>-5120  [003] .... 5987.448984: kmalloc: call_site=0xffffffff... ptr=... ... size=256 bytes gfp_flags=GFP_KERNEL

7.6 kmemleak（内存泄漏检测）

// 静态检测（kmemleak 扫描全内存，非常吃 CPU，仅限实验室使用）
// 通过 sysfs 触发扫描
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

// 典型泄漏报告
unreferenced object 0xffff... (size 256):
  comm "test_module", pid 1234, jiffies 42949...
  backtrace:
    [<ffffffff...>] kmem_cache_alloc_trace+0x145/0x270
    [<ffffffff...>] my_module_init+0x22/0x1000 [my_module]
    [<ffffffff...>] do_one_initcall+0x41/0x1e0

// 建议：开启 CONFIG_DEBUG_KMEMLEAK=y 后，新分配的 slab 对象在没有引用时每 10 分钟扫描一次

八、性能调优实战

8.1 系统参数 sysctl

// /etc/sysctl.d/99-slab.conf

# kmem slab 缓存回收积极性（默认100，越大越积极回收）
vm.min_free_kbytes = 65536      # 保留内存阈值，提升伙伴系统稳定性

# SLUB 特定
# cpu_partial: 每个 CPU 最多缓存多少空/partial 对象后才归还给节点
# -1 = 自动计算（max(cpuid/2, 32)），调整此值影响 cache 命中率
sysctl -w vm.sysctl.slub_cpu_partial=-1

# min_partial: 每个节点至少保留多少个 partial slab，防止来回震荡
# 默认值通常为 5，太小导致频繁内核-伙伴系统交互

8.2 自定义缓存调优参数

kmem_cache_create 创建缓存后可调整：

// 通过 sysfs 调整（/sys/kernel/slab/{cache} 目录）
/sys/kernel/slab/dentry/
 ├── alias         # 别名信息
 ├── align         # 对齐参数
 ├── alloc_calls   # 分配历史调用栈（SLUB_DEBUG）
 ├── cache_dma     # DMA 兼容标志
 ├── cpu_partial   # CPU 部分 slab 上限
 ├── cpu_slabs     # 每个 CPU 分配的 slab 数
 ├── ctor          # 构造函数指针
 ├── destroy_calls # 释放历史调用栈（SLUB_DEBUG）
 ├── inuse         # 使用中的对象数
 ├── min_partial   # Node 中保持的最少 partial 数
 ├── object_size   # 实际对象大小
 ├── objects       # 总对象数
 ├── order         # 每个 slab 的 2^order 页数
 ├── poison        # 是否启用毒化填充
 ├── reclaim_account # 是否参与内存回收
 ├── red_zone      # 是否启用红区保护
 ├── sanity_checks # 一致性检查
 ├── slab_size     # 每个 slab 的大小
 ├── slabs         # 总 slab 数
 ├── store_user    # 是否追踪分配者
 ├── total_objects # 总对象容量
 ├── trace         # 是否启用 tracing
 └── validate      # 深度一致性检查

8.3 常见调优场景

场景 1：高频分配小对象导致 slab 暴涨

• 症状：active_objs/num_objs 差距巨大，slabs 数持续增加
• 方案：增大 cpu_partial 或在释放路径批量归还（使用 kmem_cache_free_bulk()）

场景 2：跨 NUMA 节点频繁分配导致延迟抖动

• 症状：延迟 p99 远高于 p50，numastat.nodeX 居高不下
• 方案：设置进程 membind 或使用 SLAB_MEM_SPREAD 标志

场景 3：对象大小导致内部碎片浪费

• 症状：active_objs × sizeof(object) < active_slabs × PAGE_SIZE × 30%
• 方案：调整对象对齐要求（alignment）或拆分结构体

九、生产环境常见陷阱

9.1 双重释放（Double Free）

现象：系统卡死无日志，或突然 oom-killer 杀死关键进程

原因：代码对同一指针多次调用 kmem_cache_free() 或 kfree()

侦测：启用 slub_debug=F（一致性检查），捕获后内核打印 SLUB: Double free detected

防御：释放后立即置指针为 NULL（p = NULL），确保为防御性编程最佳实践

9.2 越界写（Out-of-Bounds Write）

现象：偶发 task_struct 字段值异常、系统随机 panic

原因：对象槽位内写入超出 objsize 的末尾数据

侦测：启用 slub_debug=Z（红区检测），内核打印 Redzone overwritten 并显示哪些 cache 受影响

防御：静态分析 Coverity + 代码审查，特别关注 memcpy 链表操作

9.3 Use-After-Free

现象：oops 中显示 0x6b6b6b6b (POISON_FREE) 模式值

原因：释放后指针仍被使用（常见于 ref-count 或 use-after-rcu）

侦测：启用 slub_debug=P（毒化填充），释放对象写入 0xa5 模式

// 1. 查看 slab 占用
$ slabtop -o | head
 OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
2155520 2155520 100%    0.19K  102720      21    821 MB  dentry   ← 800MB！
 524800  120000  22%    0.64K   26240      20    410 MB  inode_cache

// 2. 查看是否有 shrinker 阻塞
$ cat /sys/kernel/slab/dentry/reclaim_account
0    ← 问题！reclaim_account=0，导致 dentry 不参与内存回收！

// 3. 触发手动 drop_caches
$ echo 2 > /proc/sys/vm/drop_caches
$ slabtop -o | grep dentry
 OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
  1080   1080 100%    0.19K      21       21      0 MB   dentry ← 已回落