之前说了管理区页框分配器，这里我们简称为页框分配器，在页框分配器中主要是管理物理内存，将物理内存的页框分配给申请者，而且我们知道也可页框大小为4K(也可设置为4M)，这时候就会有个问题，如果我只需要1KB大小的内存，页框分配器也不得不分配一个4KB的页框给申请者，这样就会有3KB被白白浪费掉了。为了应对这种情况，在页框分配器上一层又做了一层SLAB层，SLAB分配器的作用就是从页框分配器中拿出一些页框，专门把这些页框拆分成一小块一小块的小内存，当申请者申请的是小内存时，系统就会从SLAB中获取一小块分配给申请者。它们的整个关系如下图：
可以看出，SLAB分配器和页框分配器并没有什么直接的联系，对于页框分配器来说，SLAB分配器也只是一个从它那里申请页框的申请者而已。
命令结果如下：
在SLAB中，可分配的内存块称之为对象，在后面那张图中，如kmalloc-8这个普通SLAB，里面所有的对象都是8B大小，同理，kmalloc-16中的对象都是以16B为大小。当你申请1B~8B的内存时，系统会从kmalloc-8中分配一个对象给你，当你申请8B~16B的内存时，系统会从kmalloc-16里给你分配。虽然即使申请5B，分配了一个8B的对象，还有3B空闲，但这样设计已经大大减小了内存碎片化了，保证了碎片内存不会超过50%(kmalloc-8除外)。需要注意，在kmalloc-8中申请到的对象，释放时也会回到kmalloc-8中。
除了减小了内存碎片化，SLAB还有一个作用，提高了系统的效率，当对象拥有者释放一个对象后，SLAB的处理是仅仅标记对象为空闲，并不做多少处理，而又有申请者申请相应大小的对象时，SLAB会优先分配最近释放的对象，这样这个对象甚至有可能还在硬件高速缓存中，有点类似管理区页框分配器中每CPU高速缓存的做法。
kmem_cache结构
虽然叫SLAB分配器，但是在SLAB分配器中，最顶层的数据结构却不是SLAB，而是kmem_cache，我们暂且叫它SLAB缓存吧，每个SLAB缓存都有它自己的名字，就是上图中的kmalloc-8，kmalloc-16等。总的来说，kmem_cache结构用于描述一种SLAB，并且管理着这种SLAB中所有的对象。所有的kmem_cache结构会保存在以slab_caches作为头的链表中。在内核模块中可以通过kmem_cache_create自行创建一个kmem_cache用于管理属于自己模块的SLAB。
我们先看看kmem_cache结构：
/* slab分配器中的SLAB高速缓存 */ struct kmem_cache { /* 指向包含空闲对象的本地高速缓存，每个CPU有一个该结构，当有对象释放时，优先放入本地CPU高速缓存中 */ struct array_cache __percpu *cpu_cache; /* 1) Cache tunables. Protected by slab_mutex */ /* 要转移进本地高速缓存或从本地高速缓存中转移出去的对象的数量 */ unsigned int batchcount; /* 本地高速缓存中空闲对象的最大数目 */ unsigned int limit; /* 是否存在CPU共享高速缓存，CPU共享高速缓存指针保存在kmem_cache_node结构中 */ unsigned int shared; /* 对象长度 + 填充字节 */ unsigned int size; /* size的倒数，加快计算 */ struct reciprocal_value reciprocal_buffer_size; /* 2) touched by every alloc & free from the backend */ /* 高速缓存永久属性的标识，如果SLAB描述符放在外部(不放在SLAB中)，则CFLAGS_OFF_SLAB置1 */ unsigned int flags; /* constant flags */ /* 每个SLAB中对象的个数(在同一个高速缓存中slab中对象个数相同) */ unsigned int num; /* # of objs per slab */ /* 3) cache_grow/shrink */ /* 一个单独SLAB中包含的连续页框数目的对数 */ unsigned int gfporder; /* 分配页框时传递给伙伴系统的一组标识 */ gfp_t allocflags; /* SLAB使用的颜色个数 */ size_t colour; /* SLAB中基本对齐偏移，当新SLAB着色时，偏移量的值需要乘上这个基本对齐偏移量，理解就是1个偏移量等于多少个B大小的值 */ unsigned int colour_off; /* 空闲对象链表放在外部时使用，其指向的SLAB高速缓存来存储空闲对象链表 */ struct kmem_cache *freelist_cache; /* 空闲对象链表的大小 */ unsigned int freelist_size; /* 构造函数，一般用于初始化这个SLAB高速缓存中的对象 */ void (*ctor)(void *obj); /* 4) cache creation/removal */ /* 存放高速缓存名字 */ const char *name; /* 高速缓存描述符双向链表指针 */ struct list_head list; int refcount; /* 高速缓存中对象的大小 */ int object_size; int align; /* 5) statistics */ /* 统计 */ #ifdef CONFIG_DEBUG_SLAB unsigned long num_active; unsigned long num_allocations; unsigned long high_mark; unsigned long grown; unsigned long reaped; unsigned long errors; unsigned long max_freeable; unsigned long node_allocs; unsigned long node_frees; unsigned long node_overflow; atomic_t allochit; atomic_t allocmiss; atomic_t freehit; atomic_t freemiss; /* 对象间的偏移 */ int obj_offset; #endif /* CONFIG_DEBUG_SLAB */ #ifdef CONFIG_MEMCG_KMEM /* 用于分组资源限制 */ struct memcg_cache_params *memcg_params; #endif /* 结点链表，此高速缓存可能在不同NUMA的结点都有SLAB链表 */ struct kmem_cache_node *node[MAX_NUMNODES]; };从结构中可以看出，在这个kmem_cache中所有对象的大小是相同的(object_size)，并且此kmem_cache中所有SLAB的大小也是相同的(gfporder、num)。
在这个结构中，最重要的可能就属struct kmem_cache_node * node[Max_NUMNODES]这个指针数组了，指向的struct kmem_cache_node中保存着slab链表，在NUMA架构中每个node对应数组中的一个元素，因为每个SLAB高速缓存都有可能在不同结点维护有自己的SLAB用于这个结点的分配。我们看看struct kmem_cache_node:
/* SLAB链表结构 */ struct kmem_cache_node { /* 锁 */ spinlock_t list_lock; /* SLAB用 */ #ifdef CONFIG_SLAB /* 只使用了部分对象的SLAB描述符的双向循环链表 */ struct list_head slabs_partial; /* partial list first, better asm code */ /* 不包含空闲对象的SLAB描述符的双向循环链表 */ struct list_head slabs_full; /* 只包含空闲对象的SLAB描述符的双向循环链表 */ struct list_head slabs_free; /* 高速缓存中空闲对象个数(包括slabs_partial链表中和slabs_free链表中所有的空闲对象) */ unsigned long free_objects; /* 高速缓存中空闲对象的上限 */ unsigned int free_limit; /* 下一个被分配的SLAB使用的颜色 */ unsigned int colour_next; /* Per-node cache coloring */ /* 指向这个结点上所有CPU共享的一个本地高速缓存 */ struct array_cache *shared; /* shared per node */ struct alien_cache **alien; /* on other nodes */ /* 两次缓存收缩时的间隔，降低次数，提高性能 */ unsigned long next_reap; /* 0:收缩 1:获取一个对象 */ int free_touched; /* updated without locking */ #endif /* SLUB用 */ #ifdef CONFIG_SLUB unsigned long nr_partial; struct list_head partial; #ifdef CONFIG_SLUB_DEBUG atomic_long_t nr_slabs; atomic_long_t total_objects; struct list_head full; #endif #endif };在SLAB描述符中，最重要的可能就是s_mem和freelist这两个指针。s_mem用于指向这段连续页框中第一个对象，freelist指向空闲对象链表。
空闲对象链表是一个由数组制成的简单链表，它保存的地方有两种情况：
- 保存在外部，会从SLAB中分配一个对象用于保存新的SLAB的空闲对象链表。
- 保存在内部，保存在这个SLAB所代表的连续页框的头部。
本地CPU空闲对象链表
现在说说本地CPU空闲对象链表。这个在kmem_cache结构中用cpu_cache表示，整个数据结构是struct array_cache，它的目的是将释放的对象加入到这个链表中，我们可以先看看数据结构：
struct array_cache { /* 可用对象数目 */ unsigned int avail; /* 可拥有的最大对象数目，和kmem_cache中一样 */ unsigned int limit; /* 同kmem_cache，要转移进本地高速缓存或从本地高速缓存中转移出去的对象的数量 */ unsigned int batchcount; /* 是否在收缩后被访问过 */ unsigned int touched; /* 伪数组，初始没有任何数据项，之后会增加并保存释放的对象指针 */ void *entry[]; /* };
因为每个CPU都有它们自己的硬件高速缓存，当此CPU上释放对象时，可能这个对象很可能还在这个CPU的硬件高速缓存中，所以内核为每个CPU维护一个这样的链表，当需要新的对象时，会优先尝试从当前CPU的本地CPU空闲对象链表获取相应大小的对象。这个本地CPU空闲对象链表在系统初始化完成后是一个空的链表，只有释放对象时才会将对象加入这个链表。当然，链表对象个数也是有所限制，其最大值就是limit，链表数超过这个值时，会将batchcount个数的对象返回到所有CPU共享的空闲对象链表(也是这样一个结构)中。
注意在array_cache中有一个entry数组，里面保存的是指向空闲对象的首地址的指针，注意这个链表是在kmem_cache结构中的，也就是kmalloc-8有它自己的本地CPU高速缓存链表，dquot也有它自己的本地CPU高速缓存链表，每种类型kmem_cache都有它自己的本地CPU空闲对象链表。
所有CPU共享的空闲对象链表
原理和本地CPU空闲对象链表一样，唯一的区别就是所有CPU都可以从这个链表中获取对象，一个常规的对象申请流程是这样的：系统首先会从本地CPU空闲对象链表中尝试获取一个对象用于分配；如果失败，则尝试来到所有CPU共享的空闲对象链表链表中尝试获取；如果还是失败，就会从SLAB中分配一个；这时如果还失败，kmem_cache会尝试从页框分配器中获取一组连续的页框建立一个新的SLAB，然后从新的SLAB中获取一个对象。对象释放过程也类似，首先会先将对象释放到本地CPU空闲对象链表中，如果本地CPU空闲对象链表中对象过多，kmem_cache会将本地CPU空闲对象链表中的batchcount个对象移动到所有CPU共享的空闲对象链表链表中，如果所有CPU共享的空闲对象链表链表的对象也太多了，kmem_cache也会把所有CPU共享的空闲对象链表链表中batchcount个数的对象移回它们自己所属的SLAB中，这时如果SLAB中空闲对象太多，kmem_cache会整理出一些空闲的SLAB，将这些SLAB所占用的页框释放回页框分配器中。
这个所有CPU共享的空闲对象链表也不是肯定会有的，kmem_cache中有个shared字段如果为1，则这个kmem_cache有这个高速缓存，如果为0则没有。