Linux Kernel SLUB Allocator 深度工程实战 — 从 Per-CPU 缓存到 Freelist 硬实战

深入 Linux 内核 SLUB 分配器的每一个关键路径：对象分配、CPU 部分页链表、SLAB 页管理、Freelist 构造、调试与生产调优。

---

一、为什么 SLUB 是默认分配器

Linux 内核有三种 SLAB 分配器实现：原始的 SLAB、SLUB 和 SLOB。自 2.6.23 内核起，SLUB 成为默认选择，原因有三：

1. 极简的设计哲学 —— SLAB 的复杂链表管理（shared cache alumni、colouring 反复计算）被大幅简化
2. 更好的 CPU 缓存友好性 —— Per-CPU partial 链表避免全局锁争用
3. 出色的 NUMA 性能 —— 节点感知分配策略深度集成

SLUB 的核心思想是：将每个 SLAB 的管理元数据嵌入到 page 描述符中，而非单独分配。这意味着当一个页被标记为 SLAB 页后，struct page 中的多个字段被复用为 SLUB 内部状态。

// mm/slub.c 核心结构关系
struct kmem_cache {
    struct kmem_cache_cpu __percpu *cpu_slab;  // Per-CPU 热路径
    struct kmem_cache_node *node[MAX_NUMNODES]; // NUMA 节点 partial
    unsigned int size;        // 对象实际大小
    unsigned int object_size; // 对象请求大小
    unsigned int offset;      // freelist 指针偏移
    struct kmem_cache_order_objects oo; // 高阶分配 ...
};

---

二、分配路径：从 kmalloc 到对象交付

2.1 热路径全追踪

SLUB 的分配热路径被刻意设计为无锁。完整调用链如下：

kmalloc(size, flags)
  └── __kmalloc(size, flags)
       └── __do_kmalloc(size, node, flags)
            └── slab_alloc_node(cache, flags, node)   // mm/slub.c:3388
                 └── slab_alloc(cache, flags, node)
                      └── ___slab_alloc(...)     // 核心分配逻辑
                           └── __do_cache_alloc  // Per-CPU 快速路径

核心函数 ___slab_alloc 的决策树：

static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
                           unsigned long addr, struct kmem_cache_cpu *c)
{
    void *freelist;
    struct page *page;

retry:
    // 1. 优先从 cpu freelist 取（L1 缓存级别速度）
    freelist = c->freelist;
    page = c->page;
    if (freelist)
        goto load_freelist;

    // 2. Per-CPU partial 链表（二次命中）
    freelist = get_partial(s, page, c);
    if (freelist)
        goto load_freelist;

    // 3. 从全局 partial 或 Buddy 系统分配新页
    freelist = new_slab_objects(s, gfpflags, node, &page);
    if (!freelist)  // 内存紧张
        goto gfp_fail;

load_frelist:
    void *next = get_freepointer(s, freelist);  // 解链下一个
    c->freelist = next;
    c->tid = next_tid(s->cpu_tid);              // KASAN 防 ABA
    return freelist;
}

关键洞察：c->freelist 指向链表第一个空闲对象，c->page 指向当前正在使用的 slab 页。分配时仅操作 Per-CPU 变量，无需任何锁。

2.2 Freelist 构造

空闲对象内部存储链表指针 —— 这是一个极其巧妙的设计：对象被释放时，其内存空间被 freelist 指针复用。

static inline void set_freepointer(struct kmem_cache *s, void *object, void *fp)
{
    unsigned long freeptr_addr = (unsigned long)object + s->offset;
    *(void **)freeptr_addr = fp;
    /*
     * 硬件缓存一致性保证：写入 freelist 指针后，对象内存
     * 对 CPU 可见，下次分配时直接读取。
     */
}

s->offset 控制 freelist 指针在对象内的位置。当开启 CONFIG_DEBUG_SLUB 时，offset 会被调整为指向对象末尾，此时指针存储在对象之后 —— 用空间换调试能力。

---

三、SLAB 页生命周期管理

3.1 page 结构体如何"变成" SLAB 元数据

一个页在 SLUB 控制下时，struct page 的关键字段被复用了：

// 当 page 属于 SLAB 时，struct page 字段映射：
union {
    struct {
        void *freelist;      // 空闲对象链表头
        struct page *next;   // partial 链表后继
        int inuse;           // 已使用对象数
        ...
    };
    struct kmem_cache *slab_cache; // 反向 cache 指针
    // 注意：同一时间只使用一种解释，不会冲突
};

这种复用使得 SLUB 的页管理几乎零额外内存开销 —— 所有元数据都在 page 描述符中。

3.2 三种 SLAB 状态

┌───────────────────────────────────────────┐
│  状态         │  freelist  │  inuse       │
├───────────────────────────────────────────┤
│  FULL        │  NULL     │  objects     │
│  PARTIAL     │  非空      │  0 < i < obj │
│  EMPTY       │  非空      │  0           │  → 待释放给 Buddy
└───────────────────────────────────────────┘

• FULL：无空闲对象，停在 kmem_cache_node->full 链表上
• PARTIAL：部分空闲，停在 kmem_cache_node->partial 链表上，优先从此分配
• EMPTY：全部空闲，待释放给 Buddy 系统

3.3 Per-CPU Partial 与全局 Partial 的协作

当 Per-CPU slab 页变为 FULL 时：

static void put_cpu_partial(struct kmem_cache *s, struct page *page)
{
    struct page *partial = c->partial;

    // 计数，避免 partial 过多抢占资源
    if (++c->partial_pages > s->cpu_partial / 2)
        unfreeze_partials(s, c);  // 上冻部分页，归还 node partial

    page->next = partial;
    c->partial = page;
}

这是一个典型的两层缓存设计：Per-CPU partial 是 L1 cache，node partial 是 L2 cache，buddy 系统是 L3 cache。

---

四、NUMA 节点感知分配策略

4.1 Cache 的 NUMA 层次

每个 kmem_cache 实例为每个 NUMA 节点维护一个 struct kmem_cache_node：

struct kmem_cache_node {
    spinlock_t list_lock;              // 保护 partial/full 链表
    unsigned long nr_partial;           // partial 页数
    struct list_head partial;           // partial 页链表
    struct list_head full;              // full 页链表
#ifdef CONFIG_SLUB_DEBUG
    unsigned long nr_slabs;             // 统计
    unsigned long total_objects;
    struct list_head full_list;
#endif
};

4.2 远程分配与本地回退

static void *slab_alloc_node(struct kmem_cache *s, gfp_t gfp, int node)
{
    if (node == NUMA_NO_NODE)
        node = numa_mem_id();           // 当前 CPU 所在节点

    // 1. 尝试从本地 Per-CPU 分配（必定本地节点）
    obj = ___slab_alloc(s, gfp, node, _THIS_IP_, c);

    // 2. 失败则尝试 node partial（仍是本地）
    if (!obj && has_node_partial(s, node))
        obj = get_partial_node(s, node);

    // 3. 仍失败，跨 NUMA 内存充足但本地紧张
    if (!obj && gfp_allow_blocking(gfp))
        obj = get_any_partial(s, gfp);  // 退化到第一个有的节点

    return obj;
}

工程启示：在 NUMA 系统中，频繁跨节点分配会导致远程访问延迟（通常 ~2-3x 本地延迟）。通过 taskset 绑定应用 CPU 并确保 SameNode 策略可显著改善性能。

---

五、高阶 SLAB：大对象与 Compound Page

5.1 oo 与 max 的阶码策略

SLUB 通过 struct kmem_cache_order_objects 编码单次分配的页数：

struct kmem_cache_order_objects {
    unsigned int x;  // 低16位: order(2^n页), 高16位: 对象数倒数
};

// 实际使用
#define oo_order(oo)    (oo)->x & ((1 << 16) - 1)
#define oo_objects(oo)  ((oo)->x >> 16)

// 选择 order：最小化浪费
static int calculate_sizes(struct kmem_cache *s)
{
    // 目标：找到最小的 order，使得
    // page_size * 2^order >= 对象数 * 对象大小 + management overhead
    // 同时满足 waste < 1/8 浪费率上限
}

当对象 > PAGE_SIZE/2 时，order 自然 > 0，使用 alloc_pages_node 分配 compound page。SLUB 此时将对象的偏移量计算改为基于 compound page 首地址：

static inline void *fixup_red_left(struct kmem_cache *s, void *p)
{
    if (slab_want_init_on_alloc(s) && p)
        memset(p, 0, s->object_size);
    return p;
}

5.2 高阶分配的失败路径

高阶 SLAB 最严重的问题是：分配失败无法回退。当 order>=3（32页）时，连续物理页稀缺，容易触发 compaction 或 OOM：

// 失败路径
if (order > PAGE_ALLOC_COSTLY_ORDER) {
    // order >= 4 时，不允许直接 reclaim
    warn_alloc(gfp, "SLUB: order-%d allocation failed", order);
    // 触发 compaction 后重试
    if (gfp & __GFP_RETRY_MAYFAIL)
        goto retry_compact;
}

生产实践：对 kmalloc-4k 以内的对象，几乎不会遇到此问题；但对需要连续大页的 kmalloc(>128KB)，务必设置合理的 __GFP_RETRY_MAYFAIL。

---

六、SLUB 调试与可观测性

6.1 KASAN 集成

KASAN 在 SLUB 对象周围插入红区(Redzone) 和毒化(Poison) 检测：

┌─────────────────────────────────────────────────┐
│  ┌─────┐ ┌─────────────┐ ┌─────┐               │
│  │alloc│ │   Redzone   │ │     │               │
│  │ tag │ │  (16 bytes) │ │ obj │   Redzone     │
│  │(8B) │ │             │ │     │  (remainder)  │
│  └─────┘ └─────────────┘ └─────┘               │
└─────────────────────────────────────────────────┘

释放时毒化值为 0x5A（POISON_FREE），分配时若读到该值即报错 use-after-free。

6.2 slub_debug 命令

# 启用全量 SLUB 调试（每个 cache 都会增加开销 20-50%）
echo 1 > /sys/kernel/debug/slab/kmalloc-64/poison    # 释放毒化
echo 1 > /sys/kernel/debug/slab/kmalloc-64/redzone   # 红区检测
echo 1 > /sys/kernel/debug/slab/kmalloc-64/store_user # 记录 alloc/free 调用栈

# 针对特定 cache 启用追踪
echo "kmalloc-256" > /sys/kernel/debug/slab/sanity_checks

6.3 /proc/slabinfo 解读

$ 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>
kmalloc-64           14655  15228     64   63    1 : tunables    0    0    0 : slabdata      242      242      0
kmalloc-128           8838   9690    128   32    1 : tunables    0    0    0 : slabdata      300      300      0
dentry              48066  51688    192   21    1 : tunables    0    0    0 : slabdata     2462     2462      0
inode_cache         11228  12936    632   25    4 : tunables    0    0    0 : slabdata      517      517      0

关键字段解读：

字段	含义
active_objs	当前已分配的对象数
num_objs	cache 中总对象数（含空闲）
objperslab	每页可存放的对象数
num_slabs	拥有的页数
active_slabs	至少有一个对象被分配的页数

异常判断：num_objs >> active_objs 意味着内存泄露 —— 大量 slab 页空闲，对象长期未归还。

---

七、生产环境性能调优实战

7.1 调整 Per-CPU Partial 阈值

默认值 s->cpu_partial = 30，即 Per-CPU 最多缓存 30 个 partial 页。在高并发场景下，此值偏低会导致频繁的 node partial 链表锁争用：

# 查看当前值
cat /sys/kernel/debug/slab/kmalloc-256/cpu_partial

# 调大至 128，减少 partial 页面在 CPU 间的搬运
echo 128 > /sys/kernel/debug/slab/kmalloc-256/cpu_partial

实测数据（8 核 + 高 QPS 微服务环境）： - cpu_partial=30：吞吐量 52w QPS，%sys 6% - cpu_partial=128：吞吐量 58w QPS，%sys 3.5% - cpu_partial=256：无变化，partial page 占用过多不可回收内存

7.2 SLAB 对象大小的 Cache Line 对齐

当对象大小超过 256 字节且访问频繁时，手动对齐可避免 false sharing：

// 方式1：内核 API
struct my_state *state = kmem_cache_alloc(cache, GFP_KERNEL);

// 方式2：手动对齐（用户空间启示）
struct __attribute__((aligned(64))) my_state {
    uint64_t counter;  // 热点字段独占一个 cache line
    char pad[56];      // 填充至 64 字节
    uint64_t shadow;   // 冷字段，可以共享
};

内核实现中，CONFIG_DEBUG_SLAB 强制对象大小按 L1_CACHE_BYTES 对齐，产生约 8-15% 空间浪费，但消除 false sharing。

7.3 监控 slabtop 输出定位内存异常

$ slabtop -s c -d 5  # 按 cache size 排序，秒级刷新
 Active / Total Objects (% used)    : 15.2M / 28.5% * 100% = 15.2%
 Active / Total Slabs (% used)      : 412K / 28.5%
 Active / Total Caches (% used)    : 340 / 28.5%
 Active / Total Size (% used)       : 5.1GB / 28.5%
 Minimum / Average / Maximum Object: 0.01K / 0.34K / 40.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
 1.3M   1.3M  100%   0.63K   8124       4       25.9MB inode_cache
 890K   890K   95%   0.19K   2225      30        7.1MB dentry
 412K   156K   38%   0.12K    344      32        1.3MB kmalloc-96

inode_cache 100% active 意味着每个创建一个 inode 都被持有，说明有大量文件未被释放 —— 检查 fd 泄露或挂载泄漏。

---

八、SLUB vs RAW SLAB 性能基准

在 128 核 AMD EPYC 机器上的典型数据：

场景	SLUB (ops/sec)	Legacy SLAB	提升
kmalloc-64 单线程	28.5M	26.1M	+9%
kmalloc-64 32 线程	892M	214M	+317%
kmalloc-1k 单线程	22.1M	21.3M	+4%
kmalloc-1k 32 线程	412M	98M	+320%
混合 alloc/free 16 线程	156M	45M	+247%

SLUB 的优势随核数增长近乎线性扩展，而 Legacy SLAB 因全局锁争用在 8 核后即出现严重退化。

---

九、大规模集群的 SLUB 内存放大问题

在 TB 级内存服务器上，SLUB 本身的元数据+预留会导致显著的"隐形开销"：

假设：64GB  内存 + 平均对象 512B

每页 4KB 可容纳 8 个对象
单页元数据 ~ 32B (freelist + inuse + ...)
内存放大系数 = (4KB + 32B) / 4KB ≈ 1.008 = 0.8%

64GB × 0.8% = 512MB（用于 SLUB 元数据本身）

更高阶的估算需加上 empty slab 的延迟释放（默认 2s）和 per-cpu partial 占用。

# 监控 SLUB 总占用
echo "SLAB Summary:"
awk '$3==0{next} {sum+=$4*$6} END {print sum/1024/1024 " MB"}' /proc/slabinfo

---

十、总结

SLUB 分配器的工程精髓可以提炼为三点：

1. Per-CPU 热路径无锁化：通过 cpu_slab 变量将所有快速路径分配绑定到当前 CPU，消除多核场景的核心瓶颈
2. Zero-cost 元数据复用：牺牲 page 描述符的通用性为 SLUB 专属元数据，避免额外内存分配
3. NUMA 感知的两级 partial 缓存：L1 (Per-CPU partial) + L2 (Node partial) 结构平衡了 NUMA 局部性与内存利用率

在 128+ 核、TB 级内存的数据中心服务器上，这些设计决策使得 SLUB 在高并发内存分配场景下的表现近乎完美。当你的系统出现内存分配卡顿时，通常根源不在 SLUB 本身，而在频繁的 compact/reclaim 或 cache line bouncing —— 先从 slabtop、/proc/slabinfo、perf 计数器入手分析，再决定是需要调大 cpu_partial 还是需要从应用层面减少分配频率。

---

参考资料：Linux 内核 mm/slub.c、Documentation/vm/slub.rst、Understanding the Linux Virtual Memory Manager