Linux内核学习轨迹第五部：内核内存分配器：SLUB/SLOB/SLAB全解析（第四小节）

1. Slab页：SLUB从伙伴系统分配一个或多个连续的页（Slab页），把页拆分为固定大小的对象，每个Slab页只管理一种大小的对象；
2. Kmem Cache：每种大小的对象对应一个kmem_cache缓存，比如task_struct对应一个kmem_cache，inode对应另一个kmem_cache，每个缓存管理自己的Slab页；
3. 无队列设计：SLUB没有SLAB复杂的每CPU/每节点队列，直接把空闲对象链表存储在Slab页本身，减少锁竞争，提升多核扩展性；
4. 每CPU缓存：为每个CPU维护一个活动Slab页，单CPU的对象分配和释放，直接从本地CPU的活动Slab中操作，不需要加锁，性能极高；
5. 合并缓存：SLUB会自动合并大小相近的kmem_cache，减少Slab页的数量，提升内存利用率。

struct kmem_cache { // 每CPU的活动Slab缓存，无锁快速分配 struct kmem_cache_cpu __percpu *cpu_slab; // 缓存的名称，比如"task_struct"、"kmalloc-128" const char *name; // 对象的大小，包括对齐填充 unsigned int size; // 对象的实际大小，不包括对齐填充 unsigned int object_size; // 对象的对齐要求 unsigned int align; // 每个Slab页包含的对象数量 unsigned int num; // 每个Slab页的阶数（2^order个页） unsigned int order; // 对象的偏移量，在Slab页中的起始位置 unsigned int offset; // Slab的标志位，比如SLAB_POISON、SLAB_RED_ZONE等调试标志 slab_flags_t flags; // 构造函数，对象分配时调用 void (*ctor)(void *obj); // 节点的Slab管理结构，每个NUMA节点对应一个 struct kmem_cache_node *node[MAX_NUMNODES]; // 缓存合并相关字段 struct kmem_cache *next; // 调试相关字段 int refcount; int in_slab; } ____cacheline_aligned;

1. cpu_slab：每CPU的活动Slab缓存，是SLUB快速分配的核心，每个CPU有一个独立的活动Slab页，分配和释放不需要加锁，性能极高；
2. size/object_size：对象的大小，object_size是用户实际需要的大小，size是对齐后的大小，包括填充和元数据；
3. order：每个Slab页的阶数，决定了从伙伴系统分配的连续页数量，对象越大，order越大；
4. um：每个Slab页包含的对象数量，由Slab页的总大小和对象大小决定；
5. ode[MAX_NUMNODES]：每个NUMA节点的Slab管理结构，管理该节点内的所有Slab页，包括满的、部分空闲的、完全空闲的Slab页。

struct kmem_cache_cpu { // 空闲对象链表的第一个对象，无锁分配直接从这里取 void **freelist; // 当前活动的Slab页对应的page结构体 struct page *page; // 下一个要释放的对象，用于批量释放 void **next_freelist; // 事务编号，用于调试 unsigned int tid; };

// page结构体中SLUB相关的联合体字段 struct { struct slab *slab; // 指向Slab管理结构 void *s_mem; // Slab内的第一个对象地址 union { unsigned int active; // Slab内的活跃对象数 void *freelist; // 空闲对象链表 }; };

1. 满（Full）：Slab内的所有对象都被分配了，没有空闲对象；
2. 部分空闲（Partial）：Slab内有部分对象被分配，还有空闲对象；
3. 完全空闲（Free）：Slab内的所有对象都被释放了，没有活跃对象。

1. 快速路径是无锁、无睡眠的，性能极高，99%的分配都会在快速路径完成；
2. 只有当当前CPU的活动Slab页没有空闲对象时，才会进入慢速路径，需要加锁访问节点的Partial链表，或者从伙伴系统分配新的Slab页；
3. ew_slab()函数会从伙伴系统分配对应order的连续页，初始化Slab页，把页拆分为固定大小的对象，构建空闲对象链表，设置为当前CPU的活动Slab。

1. 快速路径释放也是无锁的，直接把对象放回当前CPU活动Slab的freelist中，性能极高；
2. 只有当Slab页从满变为部分空闲，或者完全空闲时，才会进入慢速路径，需要加锁操作节点的链表，或者把Slab页释放回伙伴系统；
3. SLUB会定期把完全空闲的Slab页释放回伙伴系统，避免内存浪费，这一点和SLAB不同，SLAB会缓存大量的Slab页，不会轻易释放。

1.SLUB调试功能的使用

a.内核启动参数开启SLUB调试：

1. F：开启sanity checks，每次分配和释放都检查Slab的合法性；
2. U：开启释放后使用检测，释放的对象填充毒值，访问会触发警告；
3. Z：开启红区检测，对象前后设置红区，越界访问会触发警告；
4. P：开启Poison检测，分配的对象填充毒值，未初始化访问会触发警告；
5. A：开启所有调试功能。

调试信息查看：

cat /sys/kernel/slab//，可以查看每个缓存的分配统计、错误信息、活动对象等。

2.Slab内存泄漏排查

排查流程：

1. 查看/proc/meminfo，确认Slab、SReclaimable（可回收）、SUnreclaim（不可回收）的占用，如果SUnreclaim持续增长，说明有不可回收的Slab内存泄漏；
2. 查看/proc/slabinfo，或者slabtop命令，找到占用内存最多、对象数量持续增长的kmem_cache；
3. 开启SLUB调试，跟踪对象的分配和释放栈，找到泄漏的位置；
4. 常见根因：内核驱动分配的对象没有释放、引用计数泄漏、缓存对象没有正确回收。

临时解决方案：如果是可回收的Slab内存，可以手动回收：echo 2 > /proc/sys/vm/drop_caches，释放可回收的slab对象。

3.自定义kmem_cache的最佳实践

自定义kmem_cache的标准实现：

struct my_obj { int id; char name[32]; struct list_head list; }; // 定义缓存指针 static struct kmem_cache *my_obj_cache; // 模块初始化时创建缓存 static int __init my_module_init(void) { // 创建自定义kmem_cache my_obj_cache = kmem_cache_create( "my_obj_cache", // 缓存名称 sizeof(struct my_obj), // 对象大小 __alignof__(struct my_obj), // 对齐要求 SLAB_HWCACHE_ALIGN | SLAB_POISON, // 标志位 NULL // 构造函数 ); if (!my_obj_cache) { return -ENOMEM; } return 0; } // 分配对象 struct my_obj *obj = kmem_cache_alloc(my_obj_cache, GFP_KERNEL); // 释放对象 kmem_cache_free(my_obj_cache, obj); // 模块退出时销毁缓存 static void __exit my_module_exit(void) { // 销毁缓存前，必须确保所有对象都被释放 kmem_cache_destroy(my_obj_cache); } module_init(my_module_init); module_exit(my_module_exit);

避坑指南：模块退出时，必须确保所有从缓存中分配的对象都被释放，否则调用kmem_cache_destroy()会失败，导致内存泄漏；自定义缓存的名称必须唯一，不能和系统已有的缓存重名。

4.SLUB与SLAB的选型

1. 绝大多数场景下，使用默认的SLUB分配器即可，它的性能、扩展性、调试性都远优于SLAB；
2. 只有在内存极小的嵌入式设备，对小对象的内存利用率要求极高时，才考虑使用SLAB；
3. 只有在内存极小的单片机、物联网设备，代码量要求极简时，才考虑使用SLOB。