Linux内核内存管理深度实战：SLAB/SLUB分配器原理、调优与故障排查

引言

Linux内核的内存管理子系统是整个操作系统的核心组件之一。在用户空间，我们习惯于使用malloc()和free()来管理内存，但在内核空间，一切都要复杂得多。内核不能直接使用用户空间的内存分配机制，它需要处理中断上下文、DMA约束、内存碎片化、NUMA架构等多种复杂场景。

本文将深入剖析Linux内核的SLAB/SLUB分配器——这是内核中最重要的内存分配机制之一，理解它对于内核开发、驱动编程以及系统性能调优至关重要。

1. 内核内存分配概览

1.1 物理内存管理层级

Linux内核的内存管理从底层到上层可以分为以下几个层次：

物理内存 → 页框分配器（Buddy System） → Slab分配器（SLAB/SLUB/SLOB） → kmalloc/vmalloc → 用户空间malloc

每一层都建立在下层之上，提供更细粒度的内存管理能力。

1.2 Buddy System（伙伴系统）

伙伴系统是内核物理内存管理的基础，它负责以页（通常4KB）为单位管理物理内存。伙伴系统将空闲页面按大小分组（2^0, 2^1, 2^2, ..., 2^10个页面），当需要分配时找到合适的块，分割后返回；释放时检查相邻块是否可以合并。

伙伴系统的核心问题在于：它只能按2的幂次分配页面。如果只需要65字节的内核对象，却要分配一整页（4096字节），这造成了巨大的内部碎片。

1.3 为什么需要Slab分配器

内核运行过程中需要频繁创建和销毁大量相同大小的对象，比如：

• struct task_struct（进程描述符，约1.7KB）
• struct inode（索引节点，约600字节）
• struct dentry（目录项，约200字节）
• struct file（文件对象，约256字节）
• 网络协议栈中的socket、sk_buff等

如果每次都向伙伴系统申请整页内存再用手工方式管理，会产生严重浪费。Slab分配器的核心思想是：在内核空间中建立对象缓存，预先分配好一整页内存，然后切分成多个相同大小的对象，重复利用。

2. SLAB分配器架构原理

2.1 核心数据结构

SLAB分配器涉及三个关键数据结构：kmem_cache、slab和array_cache。

kmem_cache（缓存描述符）：代表一种特定大小的对象缓存。例如，所有struct inode对象都从"inode_cachep"缓存中分配。它包含以下关键字段：

• object_size：对象本身的大小
• size：包括元数据的实际分配大小（对齐后）
• gfporder：每个slab包含的页面数（2^n）
• num：每个slab中包含的对象数量
• colouroff：颜色偏移量（cache行对齐）
• slabs_full：已完全分配的slab链表
• slabs_partial：部分空闲的slab链表
• slabs_free：完全空闲的slab链表

slab（ slab描述符）：代表一个或多个连续的物理页面，被划分为固定大小的对象。每个slab包含：

• 指向页面结构的指针
• 空闲对象链表（free list）
• 正在使用位图（inuse bitmap）

array_cache（每CPU缓存）：每个CPU维护一个小型的空闲对象缓存。释放对象时放入本地缓存，分配时优先从本地缓存获取。这减少了锁争用，显著提升了SMP系统的性能。

2.2 对象分配流程

kmem_cache_alloc()的完整分配流程：

1. 检查per-CPU array_cache是否有空闲对象，有则直接返回
2. 从slabs_partial链表中寻找有空闲slot的slab
3. 若partial也为空，从slabs_free拿一个slab加入partial
4. 若free也为空，向伙伴系统申请新的页面，创建新slab
5. 从slab的free list中取出一个对象，标记为inuse，更新计数器

2.3 对象释放流程

kmem_cache_free()的释放流程：

1. 检查array_cache是否已满，未满则放入本地缓存
2. 若array_cache已满，批量归还一批对象到slab的free list
3. 如果slab变为全空，考虑归还页面给伙伴系统（受slab_reclaim_age控制）
4. 如果slab从full变为partial，移动到slabs_partial链表
5. 如果slab从partial变为空，移动到slabs_free链表

2.4 着色机制（Cache Coloring）

SLAB使用一种巧妙的"着色"机制来减少cache冲突。不同的slab在页面内使用不同的偏移量（colouroff）作为对象起始地址，使得不同slab中的相同编号对象映射到cache的不同的组（cache set），从而减少cache line的竞争和失效。

颜色数量由cache_line_size / object_size决定，通过colour字段配置。这类似于物理内存管理中的"pag coloring"技术。

3. SLUB：下一代Unqueued Slab分配器

3.1 SLUB的设计动机

SLAB分配器虽然设计理念优秀，但在实际使用中暴露出一些问题：：

• 每个slab维护的元数据较多，内存开销大（特别是对大量小对象）
• NUMA支持复杂，需要维护多层的node链表
• 管理逻辑复杂，代码难以维护和调试
• 对大量空闲页面的回收策略不够高效

SLUB分配器是SLAB的简化继承者，由Christoph Lameter在2.6.22引入并成为默认分配器。它的核心思路是：将slab管理元数据嵌入页面结构本身，减少额外开销；不再维护独立的slab描述符，直接将每个页面视为slab。

3.2 SLUB的核心创新

页面嵌入slab信息：SLUB不再使用独立的slab结构体。页面的struct page中新增了专用字段来管理slab状态：

• freelist：指向第一个空闲对象
• inuse：正在使用的对象数
• objects：总对象数
• frozen：是否在per-CPU partial列表上

// BPF程序追踪kmalloc调用
SEC("tracepoint/kmem/kmalloc")
int trace_kmalloc(struct trace_event_raw_kmalloc *ctx) {
    if (ctx->bytes_alloc > 65536) {
        bpf_printk("Large kmalloc: %u bytes from %d\n", 
                   ctx->bytes_alloc, bpf_get_current_pid_tgid() >> 32);
    }
    return 0;
}

# 1. 记录初始状态
cat /proc/slabinfo > /tmp/slab_before.txt
# 2. 复现问题
# 3. 记录复现后状态
cat /proc/slabinfo > /tmp/slab_after.txt
# 4. 对比差异
diff /tmp/slab_before.txt /tmp/slab_after.txt