# 3.2.5 SLAB/SLUB/SLOB
上一节我们讨论了使用Buddy System进行连续内存页面的分配，但对于使用内存的程序而言，Buddy System 还存在如下问题：
* 粒度太大：Buddy System一次最少也要分配一页内存，通常情况下是4KB, 这对于程序而言还是太大了，我们需要一种更加细致的方式来对内存进行分配与释放。
* 缺乏语义：程序在使用内存时考虑的通常也不会是“物理内存页”这种底层概念，而是程序中定义的各种具备业务意义的数据结构与对象；不仅如此，对象的初始化与释放的逻辑有时比内存分配更加耗时。
* 效率偏低：Buddy System在分配与释放内存时会对Buddy进行拆分与合并，在频繁的内存申请与释放的场景下这将非常影响性能。
为了解决这些问题，内核基于Buddy System构建了一个“对象分配系统”，该系统叫着SLAB Allocator, SLAB以对象为基本单位进行分配与释放，并且为对象提供了缓存机制，从而一举解决了上述的各种问题。
> SLAB详细思路可以参考论文：[The Slab Allocator: An Object-Caching Kernel Memory Allotor](https://people.eecs.berkeley.edu/~kubitron/courses/cs194-24-S13/hand-outs/bonwick_slab.pdf)
>
> SLUB是SLAB的改进版本，本节后续内容我们将基于SLUB的代码来讨论具体实现，但依然使用SLAB来描述对应的算法和概念。
>
> SLOB是用于嵌入式等内存容量不大的场景下的对象分配算法，这里我们不做介绍。
## 3.2.5.1 对象（Object）
> 对象（Object）一词常用于面向对象编程语言之中，从技术上讲，一个对象是一组数据（属性）与行为（方法）的封装；从业务上讲，对象用来对业务概念进行建模，以便更好地通过模块化地方式构建系统。但这里我们所说的对象确不是这个概念，此处的对象指满足内核内存申请时的任意大小的一块连续内存。
SLAB通过两个维度来区分对象：
* 用途，例如表示对象是用于通用的目的（例如用于内核的各种数据结构），还是用于特定目的（例如用于DMA）；
* 大小，从内存的视角上来看，所谓对象就是固定大小的一块连续内存，SLAB将对象通过大小进行区分，并将相同大小的对象组织在一起进行管理；
从逻辑上讲，一个SLAB Allocator管理的就是一个 <用途，大小> 形成的对象集合，Linux中所有的SLAB信息记录在 `/proc/slabinfo` 文件中，我们可以看一下其中的内容：
```
❯ sudo cat /proc/slabinfo
slabinfo - version: 2.1
# name : tunables : slabdata
kmalloc-8k 204 208 8192 4 8 : tunables 0 0 0 : slabdata 52 52 0
kmalloc-4k 709 752 4096 8 8 : tunables 0 0 0 : slabdata 94 94 0
kmalloc-2k 1266 1312 2048 16 8 : tunables 0 0 0 : slabdata 82 82 0
kmalloc-1k 2827 3008 1024 32 8 : tunables 0 0 0 : slabdata 94 94 0
kmalloc-512 54469 57856 512 32 4 : tunables 0 0 0 : slabdata 1808 1808 0
kmalloc-256 21418 21536 256 32 2 : tunables 0 0 0 : slabdata 673 673 0
kmalloc-192 43876 48867 192 21 1 : tunables 0 0 0 : slabdata 2327 2327 0
kmalloc-128 2157 2240 128 32 1 : tunables 0 0 0 : slabdata 70 70 0
kmalloc-96 2745 2772 96 42 1 : tunables 0 0 0 : slabdata 66 66 0
kmalloc-64 14032 14720 64 64 1 : tunables 0 0 0 : slabdata 230 230 0
kmalloc-32 22733 23040 32 128 1 : tunables 0 0 0 : slabdata 180 180 0
kmalloc-16 14485 14848 16 256 1 : tunables 0 0 0 : slabdata 58 58 0
kmalloc-8 10691 10752 8 512 1 : tunables 0 0 0 : slabdata 21 21 0
kmem_cache_node 576 576 64 64 1 : tunables 0 0 0 : slabdata 9 9 0
kmem_cache 352 352 256 32 2 : tunables 0 0 0 : slabdata 11 11 0
```
这里展示了系统中部分的 slab 信息，其中 `kmalloc` 是内核运行时申请内存的通用slab, 内核可能申请任意大小的内存，为了满足各种应用场景，内核预备了各种大小的 kmalloc slab, 从最小的8Byte一直到最大的8KB, 大小呈几何级数分布，并且各个 slab 的大小都满足 2n。内核申请内存时需要指定内存大小，然后系统找到满足要求的最小的 `kmalloc slab` 来进行分配。
为何 kmalloc slab 的大小呈几何级数增长呢？原因是这样的设定能够尽可能地减少内存的内部碎片（Internal Fragmentation），因为不管 slab 使用了多少个物理内存页，都能够被 slab 的对象大小所整除；另外由于相邻 slab 的大小相差两倍，所以任何分配出去的对象的使用率都会超过50%。例如一个内核的结构体刚好是17字节，满足该大小的最小的 slab 是 kmalloc-32, 这样分配出去的对象最终使用了17 字节，浪费了15字节，浪费率低于50%.
## 3.2.5.2 Slab
一个Slab包含一个或多个连续的物理页面，然后将这些页面均分成固定的大小的各等份，每一等份就是一个对象，各对象通过链表串起来。有关slab 的信息封装在 `page` 中，对应的字段如下：
```
/* file: include/linux/mm_types.h */
struct page {
union {
struct { /* slab, slob and slub */
union {
/* slab 列表，slab 可能在 partial */
struct list_head slab_list;
struct { /* Partial pages */
struct page *next;
#ifdef CONFIG_64BIT
int pages; /* Nr of pages left */
int pobjects; /* Approximate count */
#else
short int pages;
short int pobjects;
#endif
};
};
/* 使用该页作为 slab 的 kmem_cache, 通过文件 slub.c 中的函数 allocate_slab() 设置 */
struct kmem_cache *slab_cache; /* not slob */
/* 当页面用于 slab 缓存时，slab 的首页对应的 page 的该字段会指向整个 slab 的空闲对象列表。
* 但当 slab 当前正在被 kmem_cache_cpu 使用时，page 的该字段会设置为 NULL, 而 kmem_cache_cpu 中的 freelist 字段会指向 slab 的空闲对象列表 */
void *freelist; /* first free object */
union {
void *s_mem; /* slab: first object */
/* 因为 counters 与下面包含 inuse, objects, frozen 字段的结构体是 union 关系，所以很多时候需要新建 page 然后对后面三个字段赋值时，直接将 counters 的值付过去就 OK 了 */
unsigned long counters; /* SLUB */
struct { /* SLUB */
/* 记录被使用的对象，但是初始值与 objects 相同 */
unsigned inuse : 16;
/* 记录 slab 中包含 object 的总数，即为 kmem_cache 中 kmem_cache_order_objects 中低 15 位表示的值。该值在 slub.c 中的函数 allocate_slab 中设置 */
unsigned objects : 15;
/* 标记该 slab 是否被某个 cpu “锁定”，如果处于 frozen 状态，那么只有对应的CPU 能够从该slab中分配对象，其他CPU 只能往该页面释放对象。初始值设置为 1 */
unsigned frozen : 1;
};
};
};
} _struct_page_alignment;
```
如果页面被分配用于 slab, 那么这些字段就会被设置。其中 `kmem_cache` 与注释中提到的 `kmem_cache_cpu` 等结构会在下一节介绍。内核创建一个slab的逻辑也很直观：首先向Buddy System申请一定数量的连续页面，然后初始化对象并构建好对象列表。代码如下：
```
/* file: mm/slub.c */
static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
{
struct page *page;
/* 结构 kmem_cache_order_objects 中记录着一个 slab 应该申请的页面数量与总的对象数量，两个量封装在一个字段 unsigned int x 中，其中低16位表示对象总数，高位表示连续页面的阶，即需要分配2^(oo.x >> 16)个连续页面 */
struct kmem_cache_order_objects oo = s->oo;
/* 传给Buddy System的各类Flag, 这里我们删掉了对该参数的初始化逻辑 */
gfp_t alloc_gfp;
/* 初始化对象列表时使用的指针变量 */
void *start, *p, *next;
int idx;
bool shuffle;
/* 分配连续 2^(oo.x>>OO_SHIFT) 个连续页面，其中 OO_SHIFT 为 16 */
page = alloc_slab_page(s, alloc_gfp, node, oo);
if (unlikely(!page)) {
/* 如果 buddy system 没有足够的连续物理页，则减少 oo 的数值再尝试一次 */
oo = s->min;
alloc_gfp = flags;
page = alloc_slab_page(s, alloc_gfp, node, oo);
/* s->min 是实例化一个 slab 所需要的最小的内存页数量，如果依旧无法满足的话就直接退出了 */
if (unlikely(!page))
goto out;
stat(s, ORDER_FALLBACK);
}
/* oo.x 的低 15 位表示该 slab 中可以存放的 object 总数 */
/* 函数oo_objects 就是取出 oo.x 的低16位的数字，即 oo.x&(1<<16 -1) 的值*/
page->objects = oo_objects(oo);
/* 将 kmem_cache 记录到第一个内存页中，kmem_cache 在下一节介绍 */
page->slab_cache = s;
/* 设置 page 的标记位，标记该页面用于 slab */
__SetPageSlab(page);
start = page_address(page);
shuffle = shuffle_freelist(s, page);
/* if block 中构建对象列表 */
if (!shuffle) {
/* 初始化第一个对象，因为 for 循环中处理的都是下一个对象 */
start = fixup_red_left(s, start);
/* 如果为 slab 配置了对象的初始化函数，则会在函数 setup_object 调用，对每个对象进行初始化 */
start = setup_object(s, page, start);
/* slab 中空闲对象列表的地址为第一个对象 */
page->freelist = start;
/* 初始化 slab 中的空闲对象列表 */
for (idx = 0, p = start; idx < page->objects - 1; idx++) {
/* s->size 表示每个对象的大小，这里计算出下一个对象的地址 */
next = p + s->size;
/* 初始化下一个对象 */
next = setup_object(s, page, next);
/* 建立空闲对象列表的单链表，其中 p 为当前对象，next 为下一个对象，将 next 的地址写入 p+s.offset 位置处 */
set_freepointer(s, p, next);
p = next;
}
/* 链表最后一个元素的next属性指向 NULL */
set_freepointer(s, p, NULL);
}
page->inuse = page->objects;
page->frozen = 1;
out:
if (!page)
return NULL;
return page;
}
```
在前文中我们提到过slab中的对象就是一个固定大小的连续内存块，通过对象列表的构建逻辑我们可以对此有更深刻的理解，内核并没有单独定义一个结构体来封装对象信息，在构建对象列表时，指向下一个空闲对象的指针也是直接存放在该对象的内存地址内部，因为对象还没有被分配出去时内存是不会被使用的，而被分配之后也不需要该指针了，这是一个比较精巧的设计。一个初始化完毕的 slab 的示意图如下所示：
freelist 总是指向slab 中第一个空闲对象，也是 slab 分配与释放对象的入口点，这在后续章节会详细介绍。
## 3.2.5.3 缓存（Cache）
前面讨论了 slab 如何组织管理对象，但我们还面临如下问题：
* 性能问题：多核系统中，如果多个CPU都使用共享的slab, 那么在分配与释放对象时会面临强烈的竞争问题，从而极大影响系统性能；
* 如何管理多个slab: 上一节只讲到了内核如何初始化一个slab, slab 从Buddy System中分配的内存页面是固定的，当slab中的对象耗尽之后内核需要重新创建新的slab, 如何管理这些相同类型的 slab 也是一个问题；
内核引入了缓存的概念来解决这些问题。一个缓存使用一个 `kmem_cache` 来表示，该结构体的定义如下：
```
/* file: include/linux/slub_def.h */
struct kmem_cache {
/* 为每个CPU单独维护的slab, 避免竞争带来的冲突，这也是分配对象时的快速通道 */
struct kmem_cache_cpu __percpu *cpu_slab;
/* 包含了 metadata 的对象大小 */
unsigned int size; /* The size of an object including metadata */
/* 不包含 metadata 的对象大小 */
unsigned int object_size; /* The size of an object without metadata */
/* 空闲对象中保存 next 指针的偏移 */
unsigned int offset; /* Free pointer offset */
#ifdef CONFIG_SLUB_CPU_PARTIAL
/* Number of per cpu partial objects to keep around */
unsigned int cpu_partial;
#endif
/* kmem_cache_order_objects 用来存放一个 slab 中的实际物理页数，以及对象的总数。*/
struct kmem_cache_order_objects oo;
struct kmem_cache_order_objects max;
struct kmem_cache_order_objects min;
/* 对象的构造函数，如果非空的话，slab 在初始化时就会通过该函数初始化每个对象 */
void (*ctor)(void *);
unsigned int inuse; /* Offset to metadata */
unsigned int align; /* Alignment */
const char *name; /* Name (only for display!) */
struct list_head list; /* List of slab caches */
/* 存放缓存中的备用 slab, */
struct kmem_cache_node *node[MAX_NUMNODES];
};
```
我们在前文讨论 slab 初始化时已经见过该结构体，并且已经使用过其中的某些字段，例如用来确定 slab 页面数量与对象数量的字段 `struct kmem_cache_order_objects oo;`
内核使用 `kmem_cache` 来管理同一类对象的所有 slab, 其中最重要的两个字段是 `struct kmem_cache_cpu __percpu * cpu_slab` 与 `struct kmem_cache_node * node[MAX_NUMNODES]`. 为了避免分配对象时的竞争问题， `kmem_cache` 为每个CPU都单独维护了一个slab 缓存，变量 `cpu_slab` 的修饰符 `__percpu` 就是告诉编译器，该字段是 per cpu 的。该结构体定义如下：
```
/* file: include/linux/slub_def.h */
struct kmem_cache_cpu {
/* 指向下一个空闲对象 */
void **freelist; /* Pointer to next available object */
/* 事务 ID, 用来做同步。kmem_cache_cpu 是分配对象的快速路径，因此性能是首要考虑因素，所以此处没有考虑使用加锁的方式来进行同步 */
unsigned long tid; /* Globally unique transaction id */
/*
* 指向当前 slab 的首个物理页面
*/
struct page *page; /* The slab from which we are allocating */
};
```
内核申请对象时，CPU都会首先尝试从自己的缓存对象 `kmem_cache_cpu` 中进行分配，这是效率最高的分配通道。
既然CPU使用的是自己独占的缓存对象了，那么为什么还需要字段 `tid` 来做同步呢？因为虽然CPU不用与其它CPU竞争资源，但在对象分配过程中调度器可能切入触发任务切换，当前任务在下次被调度时可能就跑到了其它CPU上去执行了；或者当前CPU可能发生中断，而中断处理程序可能会从同一个Slab缓存中申请对象，因此我们需要一种机制来保证对象分配发生在同一个CPU上，并且分配过程中不会被干扰，slab 通过 tid 来实现这一点。tid 是一个全局递增的数字，slab 在每次开始分配对象前会读取到当前的tid数值，完成分配后将 tid 递增，然后通过原子操作CAS(Compare And Set) 来同时更新 freelist 与 tid 两个值，这样如果中途有其它的分配操作乱入的话，CAS 操作就会失败，slab 就会重头开始重新进行分配，直到成功为止。该段逻辑在函数 `slab_alloc_node` 中，这里我们在不深入具体分配逻辑的情况下看一下同步策略：
```
/* file: mm/slub.c */
static __always_inline void *slab_alloc_node(struct kmem_cache *s,
gfp_t gfpflags, int node,
unsigned long addr,
size_t orig_size)
{
void *object;
struct kmem_cache_cpu *c;
struct page *page;
unsigned long tid;
redo:
/* 1. 分配逻辑开始时获取到当前 tid */
do {
tid = this_cpu_read(s->cpu_slab->tid);
c = raw_cpu_ptr(s->cpu_slab);
} while (IS_ENABLED(CONFIG_PREEMPTION) &&
unlikely(tid != READ_ONCE(c->tid)));
/* 从当前 kmem_cache_cpu 的 free list 中拿到第一个对象 */
/* 2. 分配对象并计算下一个空闲对象的地址，即freelist 的新值*/
object = c->freelist;
void *next_object = get_freepointer_safe(s, object);
/* 3. 通过 CMPXCHG 指令设置 freelist 与 tid 的新值, 如果此时的 tid 与 s->cpu_slab->tid 不同，则说明发生了干扰，代码跳转到 redo 重新开始分配逻辑 */
if (unlikely(!this_cpu_cmpxchg_double(
s->cpu_slab->freelist, s->cpu_slab->tid, object,
tid, next_object, next_tid(tid)))) {
goto redo;
}
out:
return object;
}
```
如果CPU的本地缓存没有空闲对象，那么就需要从其它地方拿一个可用的slab过来，这个地方就是 `kmem_cache_node`, 这相当于 `kmem_cache` 的一个中心化仓库，用来管理暂时没有被 `kmem_cache_cpu` 使用到的slab. 前文介绍NUMA架构时提到过内存会根据CPU的拓扑结果划分成不同的Node, 为了区分从不同Node 分配过来的 slab, kmemcache 也根据Node对 `kmem_cache_node` 进行了区分，该字段是一个与Node数量相等的数组。
`kmem_cache_node` 的定义如下：
```
/* file: mm/slab.h */
struct kmem_cache_node {
spinlock_t list_lock;
#ifdef CONFIG_SLUB
unsigned long nr_partial;
/* 指向 partial slab 的链表，partial 的意思是 slab 中还有剩余的空闲对象可用 */
struct list_head partial;
#ifdef CONFIG_SLUB_DEBUG
atomic_long_t nr_slabs;
atomic_long_t total_objects;
/* 指向 full slab 的链表，full 的意思是 slab 中所有的对象都已经被分配出去了，没有可用的空闲对象 */
struct list_head full;
#endif
#endif
};
```
这里我们只留下了与 `SLUB` 算法相关的部分，一个 `kmem_cache_node` 实际上就包含了两个列表，一个是partial slab列表，一个是full slab列表。示意图如下：
综合起来看，一个缓存 `kmem_cache` 管理着一个特定类型的所有slab, `kmem_cache_cpu` 中包含着当前CPU正在使用的slab, 任何对象分配的请求都直接从该slab中进行分配；而 `kmem_cache_node` 用来充当 `kmem_cache_cpu` 与Buddy System之间的缓冲区，当 `kmem_cache_cpu` 中的空闲对象分配完了之后，会将 slab 放入 `kmem_cache_node` 的full 列表，并从 partial 列表获取新的 slab 来使用，而当 `kmem_cache_node` 也没有多余的 slab 时，便会从Buddy System 中分配新的 slab 进行补充。同时，如果系统对该类对象的使用量下降，导致 `kmem_cache_node` 有很多完全空闲的 slab 时，系统也会酌情返回一些 slab 给Buddy System, 以缓解系统的总体内存压力。
所有的 `kmem_cache` 保留在全局变量 `kmalloc_caches` 中，代码如下：
```
/* file: mm/slab_common.c */
struct kmem_cache *kmalloc_caches[NR_KMALLOC_TYPES][KMALLOC_SHIFT_HIGH +
1] __ro_after_init = {
/* initialization for https://bugs.llvm.org/show_bug.cgi?id=42570 */
};
/* file: include/linux/slab.h */
/* 通过内存用途对 kmem_cache 进行分类 */
enum kmalloc_cache_type {
KMALLOC_NORMAL = 0,
KMALLOC_RECLAIM,
#ifdef CONFIG_ZONE_DMA
KMALLOC_DMA,
#endif
NR_KMALLOC_TYPES
};
```
总结起来，系统所有 kmemcache 的示意图如下：
## 3.2.5.4 分配（Allocation) 与释放（Free）
通过前文对几个核心概念的分析，我们可以总结出关于SLAB的一些关键设计思想：
* 懒加载（Lazy Loading）：缓存 `kmem_cache` 初始化时只会创建出 `kmem_cache_cpu` 与 `kmem_cache_node`, 但对slab的初始化会推迟到对象分配时才会发生，这可以降低系统总体的内存压力，因为除了SLAB 系统，整个内核在很多其它地方还需要使用内存；
* 本地化（Locality）：为了减少竞争，每个CPU都持有一个自己的 slab, 做到独立运作不冲突；
本节我们将继续深入，探讨SLAB系统分配对象的详细流程，以及如何与Buddy System进行交互的。内核申请内存的入口函数是 `kmalloc`:
```
/* file: include/linux/slab.h */
/* 函数有两个参数，size 表示连续的内存大小；flags用来指定内存种类（即内存分区）与内核分配内存时的行为（例如是否允许分配失败）。 */
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
/* 删除部分无关代码 */
return __kmalloc(size, flags);
}
/* file: mm/slab.c */
void *__kmalloc(size_t size, gfp_t flags)
{
/* _RET_IP_ 是 GCC 的一个内置函数，参考 https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html */
return __do_kmalloc(size, flags, _RET_IP_);
}
```
函数简单地调用 `__kmalloc` 并最终调用到 `__do_kmalloc`, 该函数通过内存大小与 `flags` 中的内存种类找到对应的 `kmem_cache`, 然后从该缓存中分配对象：
```
/* file: mm/slab.c */
static __always_inline void *__do_kmalloc(size_t size, gfp_t flags,
unsigned long caller)
{
struct kmem_cache *cachep;
void *ret;
/* KMALLOC_MAX_CACHE_SIZE 为 page * 2, 超过该大小的内存分配请求需要使用 page allocator */
if (unlikely(size > KMALLOC_MAX_CACHE_SIZE))
return NULL;
/* 根据 size 和内存类型找出对应的 kmem_cache, 然后从 cachep 中分配空闲对象。函数 kmalloc_slab 就是从全局变量 kmalloc_caches 找出对应的缓存 */
cachep = kmalloc_slab(size, flags);
if (unlikely(ZERO_OR_NULL_PTR(cachep)))
return cachep;
/* 从缓存中分配对象 */
ret = slab_alloc(cachep, flags, size, caller);
return ret;
}
```
从缓存中分配对象有两条路径：
* 快路径（fastpath）：直接从 `kmem_cache_cpu` 中的slab 中分配到对象
* 慢路径（slowpath）：无法直接从 `kmem_cache_cpu` 中分配到对象，需要先从 `kmem_cache_node` 的 partial 列表拿一个slab，甚至需要从Buddy System 中分配一个全新的 slab 来进行补充
快路径的逻辑在函数 `slab_alloc_node` 中，前文讨论 `kmem_cache_cpu` 的并发控制时已经探索过该函数，这里再着重看一下有关对象分配的逻辑：
```
/* file: mm/slub.c */
static __always_inline void *slab_alloc_node(struct kmem_cache *s,
gfp_t gfpflags, int node,
unsigned long addr,
size_t orig_size)
{
void *object;
struct kmem_cache_cpu *c;
struct page *page;
unsigned long tid;
redo:
do {
tid = this_cpu_read(s->cpu_slab->tid);
/* 拿到当前 CPU 的 kmem_cache_cpu */
c = raw_cpu_ptr(s->cpu_slab);
} while (IS_ENABLED(CONFIG_PREEMPTION) &&
unlikely(tid != READ_ONCE(c->tid)));
/* 从 kmem_cache_cpu 的 freelist 中拿到第一个对象 */
object = c->freelist;
page = c->page;
if (unlikely(!object || !page || !node_match(page, node))) {
/* 进入慢路径进行分配。!object 表示 kmem_cache_cpu 的slab 中已经没有了空闲对象，!page 表示还没有为 kmem_cache_cpu 分配 slab, 不管哪种情况，都需要先搞定一个 slab 才能继续分配对象。 */
object = __slab_alloc(s, gfpflags, node, addr, c);
} else {
/* 快路径分配成功，修改各个变量，同步原理在前文中已经讲过 */
void *next_object = get_freepointer_safe(s, object);
if (unlikely(!this_cpu_cmpxchg_double(
s->cpu_slab->freelist, s->cpu_slab->tid, object,
tid, next_object, next_tid(tid)))) {
note_cmpxchg_failure("slab_alloc", s, tid);
goto redo;
}
}
out:
/* 对分配到的对象做一些边界检查等工作 */
slab_post_alloc_hook(s, objcg, gfpflags, 1, &object);
return object;
}
```
慢路径的逻辑在函数 `___slab_alloc` 中，其主要思想是先尝试着从 `kmem_cache_node` 的partial 列表获取一个slab, 不行的话就从Buddy System 申请一个全新的slab 来使用。主要代码如下：
```
/* file: mm/slub.c */
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;
page = c->page;
if (!page) {
/* 说明当前CPU的slab还为空，尝试分配一个新的 slab */
if (unlikely(node != NUMA_NO_NODE &&
!node_isset(node, slab_nodes)))
node = NUMA_NO_NODE;
goto new_slab;
}
/* 分配对象的代码块 */
redo:
/* must check again c->freelist in case of cpu migration or IRQ */
/* 再次检查 c->freelist，如果分配成功则跳转到 load_freelist 做后续处理 */
freelist = c->freelist;
if (freelist)
goto load_freelist;
/* 如果 kmem_cache_cpu 的 freelist 已经没有空闲对象，而 page 可能是重新分配的 slab, 该函数将 page 中的 freelist 转移出来。
* 在 reload_freelist 部分会将该 freelist 设置到 kmem_cache_cpu 中。总体来说，该操作就是为了将新的slab设置到 kmem_cache_cpu 中
*/
freelist = get_freelist(s, page);
if (!freelist) {
c->page = NULL;
goto new_slab;
}
load_freelist:
/* 设置 slab 到 kmem_cache_cpu 中 */
c->freelist = get_freepointer(s, freelist);
c->tid = next_tid(c->tid);
/* 分配成功，返回 */
return freelist;
new_slab:
/* 函数 new_slab_objects 会先检查 kmem_cache_node 的partial 列表，如果列表为空则从Buddy System 重新分配 slab */
freelist = new_slab_objects(s, gfpflags, node, &c);
if (unlikely(!freelist)) {
slab_out_of_memory(s, gfpflags, node);
return NULL;
}
page = c->page;
if (likely(!kmem_cache_debug(s) && pfmemalloc_match(page, gfpflags)))
goto load_freelist;
/* 该函数会将新分配的 slab 放入 kmem_cache_node 的 partial 列表中 */
deactivate_slab(s, page, get_freepointer(s, freelist), c);
return freelist;
}
```
从Buddy System 分配与初始化slab 的函数在前面已经介绍过，这里不再讨论。
向缓存中释放对象时逻辑很简单，就是将该对象放入对应slab 的freelist 列表即可。但在如下几种情况下会调整slab 的位置：
* slab 在 kmemcachenode 的full 列表中时，需要将该slab 放入 partial 列表中
* slab 变成完全空闲状态时，即没有对象被使用，那么如果此时 kmemcachenode 有太多 slab 的话，需要将整个 slab 释放，将内存还给Buddy System