在上篇文章《深刻了解 slab cache 内存调配全链路实现》中，笔者具体地为大家介绍了 slab cache 进行内存调配的整个链路实现，本文咱们就来到了 slab cache 最初的一部分内容了，当申请的内存应用结束之后，上面就该开释内存了。
在接下来的内容中，笔者为大家介绍一下内核是如何将内存块开释回 slab cache 的。咱们还是先从 slab cache 开释内存的内核 API 开始聊起~~~
内核提供了 kmem_cache_free 函数，用于将对象开释回其所属的 slab cache 中，参数 x 示意咱们要开释的内存块（对象）的虚拟内存地址，参数 s 指向内存块所属的 slab cache。
void kmem_cache_free(struct kmem_cache *s, void *x)
{
// 确保指定的是 slab cache : s 为对象真正所属的 slab cache
s = cache_from_obj(s, x);
if (!s)
return;
// 将对象开释会 slab cache 中
slab_free(s, virt_to_head_page(x), x, NULL, 1, _RET_IP_);
}1. 内存开释之前的校验工作
在开始开释内存块 x 之前，内核须要首先通过 cache_from_obj 函数确认内存块 x 是否真正属于咱们指定的 slab cache。不能将内存块开释到其余的 slab cache 中。
随后在 virt_to_head_page 函数中通过内存块的虚拟内存地址 x 找到其所在的物理内存页 page。而后调用 slab_free 将内存块开释回 slab cache 中。
通过虚拟内存地址寻找物理内存页 page 的过程波及到的背景常识比较复杂，这个笔者前面会独自拎进去介绍，这里大家只须要简略理解 virt_to_head_page 函数的作用即可。
static inline struct kmem_cache *cache_from_obj(struct kmem_cache *s, void *x)
{
struct kmem_cache *cachep;
// 通过对象的虚拟内存地址 x 找到对象所属的 slab cache
cachep = virt_to_cache(x);
// 校验指定的 slab cache : s 是否是对象真正所属的 slab cache : cachep
WARN_ONCE(cachep && !slab_equal_or_root(cachep, s),
"%s: Wrong slab cache. %s but object is from %s\n",
__func__, s->name, cachep->name);
return cachep;
}virt_to_cache 函数首先会通过开释对象的虚拟内存地址找到其所在的物理内存页 page，而后通过 struct page 构造中的 slab_cache 指针找到 page 所属的 slab cache。
static inline struct kmem_cache *virt_to_cache(const void *obj)
{
struct page *page;
// 依据对象的虚拟内存地址 *obj 找到其所在的内存页 page
// 如果 slub 背地是多个内存页（复合页），则返回复合页的首页 head page
page = virt_to_head_page(obj);
if (WARN_ONCE(!PageSlab(page), "%s: Object is not a Slab page!\n",
__func__))
return NULL;
// 通过 page 构造中的 slab_cache 属性找到其所属的 slub
return page->slab_cache;
}2. slab cache 在疾速门路下回收内存
static __always_inline void slab_free(struct kmem_cache *s, struct page *page,
void *head, void *tail, int cnt,
unsigned long addr)
{if (slab_free_freelist_hook(s, &head, &tail))
do_slab_free(s, page, head, tail, cnt, addr);
}slab cache 回收内存相干的逻辑封装在 do_slab_free 函数中：
static __always_inline void do_slab_free(struct kmem_cache *s,
struct page *page, void *head, void *tail,
int cnt, unsigned long addr)- 参数 kmem_cache *s 示意开释对象所在的 slab cache，指定咱们要将对象开释到哪里。
- 参数 page 示意开释对象所在的 slab，slab 在内核中应用 struct page 构造来示意。
- 参数 head 指向开释对象的虚拟内存地址（起始内存地址）。
- 该函数反对向 slab cache 批量的开释多个对象，参数 tail 指向批量开释对象中最初一个对象的虚拟内存地址。
- 参数 cnt 示意开释对象的个数，也是用于批量开释对象
- 参数 addr 用于 slab 调试，这里咱们不须要关怀。
slab cache 针对内存的回收流程其实和咱们在上篇文章《深刻了解 slab cache 内存调配全链路实现》中介绍的 slab cache 内存调配流程是类似的。
内存回收总体也是分为疾速门路 fastpath 和慢速门路 slow path，在 do_slab_free 函数中内核会首先尝试 fastpath 的回收流程。
如果开释对象所在的 slab 刚好是 slab cache 在本地 cpu 缓存 kmem_cache_cpu->page 缓存的 slab，那么内核就会间接将对象开释回缓存 slab 中。
static __always_inline void do_slab_free(struct kmem_cache *s,
struct page *page, void *head, void *tail,
int cnt, unsigned long addr)
{
void *tail_obj = tail ? : head;
struct kmem_cache_cpu *c;
// slub 中对象调配与开释流程的全局事务 id
// 既能够用来标识同一个调配或者开释的事务流程，也能够用来标识辨别所属 cpu 本地缓存
unsigned long tid;
redo:
// 接下来咱们须要获取 slab cache 的 cpu 本地缓存
// 这里的 do..while 循环是要保障获取到的 cpu 本地缓存 c 是属于执行过程的以后 cpu
// 因为过程可能因为抢占或者中断的起因被调度到其余 cpu 上执行，所需须要确保两者的 tid 是否统一
do {
// 获取执行以后过程的 cpu 中的 tid 字段
tid = this_cpu_read(s->cpu_slab->tid);
// 获取 cpu 本地缓存 cpu_slab
c = raw_cpu_ptr(s->cpu_slab);
// 如果两者的 tid 字段不统一，阐明过程曾经被调度到其余 cpu 上了
// 须要再次获取正确的 cpu 本地缓存
} while (IS_ENABLED(CONFIG_PREEMPT) &&
unlikely(tid != READ_ONCE(c->tid)));
// 如果开释对象所属的 slub（page 示意）正好是 cpu 本地缓存的 slub
// 那么间接将对象开释到 cpu 缓存的 slub 中即可，这里就是疾速开释门路 fastpath
if (likely(page == c->page)) {
// 将对象开释至 cpu 本地缓存 freelist 中的头结点处
// 开释对象中的 freepointer 指向原来的 c->freelist
set_freepointer(s, tail_obj, c->freelist);
// cas 更新 cpu 本地缓存 s->cpu_slab 中的 freelist，以及 tid
if (unlikely(!this_cpu_cmpxchg_double(
s->cpu_slab->freelist, s->cpu_slab->tid,
c->freelist, tid,
head, next_tid(tid)))) {note_cmpxchg_failure("slab_free", s, tid);
goto redo;
}
stat(s, FREE_FASTPATH);
} else
// 如果以后开释对象并不在 cpu 本地缓存中，那么就进入慢速开释门路 slowpath
__slab_free(s, page, head, tail_obj, cnt, addr);
} 既然是疾速门路开释，那么在 do_slab_free 函数的开始首先就获取 slab cache 的本地 cpu 缓存构造 kmem_cache_cpu，为了保障咱们获取到的 cpu 本地缓存构造与运行以后过程所在的 cpu 是相符的，所以这里还是须要在 do .... while 循环内判断两者的 tid。这一点，笔者曾经在本文之前的内容里屡次强调过了，这里不在赘述。
内核在确保曾经获取了正确的 kmem_cache_cpu 构造之后，就会马上判断该开释对象所在的 slab 是否正是 slab cache 本地 cpu 缓存了的 slab —— page == c->page。
如果是的话，间接将对象开释回缓存 slab 中，调整 kmem_cache_cpu->freelist 指向刚刚开释的对象，调整开释对象的 freepointer 指针指向原来的 kmem_cache_cpu->freelist。
如果以后开释对象并不在 slab cache 的本地 cpu 缓存中，那么就会进入慢速门路 slowpath 开释内存。
3. slab cache 在慢速门路下回收内存
slab cache 在慢速门路下回收内存的逻辑比较复杂，因为这里波及到很多的场景，须要扭转开释对象所属 slab 在 slab cache 架构中的地位。
上面笔者会带大家一一梳理这些场景，咱们一起来看一下内核在这些不同场景中到底是如何解决的？
在开始浏览本大节的内容之前，倡议大家先回顾下《细节拉满，80 张图带你一步一步推演 slab 内存池的设计与实现》一文中的”8. slab 内存开释原理“大节。
在将对象开释回对应的 slab 中之前，内核须要首先清理一下对象所占的内存，从新填充对象的内存布局复原到初始未应用状态。因为对象所占的内存此时蕴含了很多曾经被应用过的无用信息。这项工作内核在 free_debug_processing 函数中实现。
在将对象所在内存复原到初始状态之后，内核首先会将对象间接开释回其所属的 slab 中，并调整 slab 构造 page 的相干属性。
接下来就到简单的解决局部了，内核会在这里解决多种场景，并扭转 slab 在 slab cache 架构中的地位。
- 如果 slab 原本就在 slab cache 本地 cpu 缓存 kmem_cache_cpu->partial 链表中，那么对象在开释之后，slab 的地位不做任何扭转。
- 如果 slab 不在 kmem_cache_cpu->partial 链表中，并且该 slab 因为对象的开释刚好由一个 full slab 变为了一个 partial slab，为了利用局部性的劣势，内核须要将该 slab 插入到 kmem_cache_cpu->partial 链表中。
- 如果 slab 不在 kmem_cache_cpu->partial 链表中，并且该 slab 因为对象的开释刚好由一个 partial slab 变为了一个 empty slab，阐明该 slab 并不是很沉闷，内核会将该 slab 放入对应 NUMA 节点缓存 kmem_cache_node->partial 链表中，刀枪入库，马放南山。
- 如果不合乎第 2, 3 种场景，然而 slab 原本就在对应的 NUMA 节点缓存 kmem_cache_node->partial 链表中，那么对象在开释之后，slab 的地位不做任何扭转。
上面咱们就到内核的源码实现中，来一一验证这四种慢速开释场景。
static void __slab_free(struct kmem_cache *s, struct page *page,
void *head, void *tail, int cnt,
unsigned long addr)
{
// 用于指向对象开释回 slub 之前，slub 的 freelist
void *prior;
// 对象所属的 slub 之前是否在本地 cpu 缓存 partial 链表中
int was_frozen;
// 后续会对 slub 对应的 page 构造相干属性进行批改
// 批改后的属性会长期保留在 new 中，前面通过 cas 替换
struct page new;
unsigned long counters;
struct kmem_cache_node *n = NULL;
stat(s, FREE_SLOWPATH);
// free_debug_processing 中会调用 init_object，清理对象内存无用信息，从新复原对象内存布局到初始状态
if (kmem_cache_debug(s) &&
!free_debug_processing(s, page, head, tail, cnt, addr))
return;
do {
// 获取 slub 中的闲暇对象列表，prior = null 示意此时 slub 是一个 full slub，意思就是该 slub 中的对象曾经全副被调配进来了
prior = page->freelist;
counters = page->counters;
// 将开释的对象插入到 freelist 的头部，将对象开释回 slub
// 将 tail 对象的 freepointer 设置为 prior
set_freepointer(s, tail, prior);
// 将原有 slab 的相应属性赋值给 new page
new.counters = counters;
// 获取原来 slub 中的 frozen 状态，是否在 cpu 缓存 partial 链表中
was_frozen = new.frozen;
// inuse 示意 slub 曾经调配进来的对象个数，这里是开释 cnt 个对象，所以 inuse 要减去 cnt
new.inuse -= cnt;
// !new.inuse 示意此时 slub 变为了一个 empty slub，意思就是该 slub 中的对象还没有调配进来，全副在 slub 中
// !prior 示意因为本次对象的开释，slub 刚刚从一个 full slub 变成了一个 partial slub (意思就是该 slub 中的对象局部调配进来了，局部没有调配进来)
// !was_frozen 示意该 slub 不在 cpu 本地缓存中
if ((!new.inuse || !prior) && !was_frozen) {
// 留神：进入该分支的 slub 之前都不在 cpu 本地缓存中
// 如果配置了 CONFIG_SLUB_CPU_PARTIAL 选项，那么示意 cpu 本地缓存 kmem_cache_cpu 构造中蕴含 partial 列表，用于 cpu 缓存局部调配的 slub
if (kmem_cache_has_cpu_partial(s) && !prior) {
// 如果 kmem_cache_cpu 蕴含 partial 列表并且该 slub 刚刚由 full slub 变为 partial slub
// 解冻该 slub，后续会将该 slub 插入到 kmem_cache_cpu 的 partial 列表中
new.frozen = 1;
} else {
// 如果 kmem_cache_cpu 中没有配置 partial 列表，那么间接开释至 kmem_cache_node 中
// 或者该 slub 由一个 partial slub 变为了 empty slub，调整 slub 的地位到 kmem_cache_node->partial 链表中
n = get_node(s, page_to_nid(page));
// 后续会操作 kmem_cache_node 中的 partial 列表，所以这里须要获取 list_lock
spin_lock_irqsave(&n->list_lock, flags);
}
}
// cas 更新 slub 中的 freelist 以及 counters
} while (!cmpxchg_double_slab(s, page,
prior, counters,
head, new.counters,
"__slab_free"));
// 该分支要解决的场景是：// 1: 该 slub 原来不在 cpu 本地缓存的 partial 列表中（!was_frozen），然而该 slub 刚刚从 full slub 变为了 partial slub，须要放入 cpu-> partial 列表中
// 2: 该 slub 原来就在 cpu 本地缓存的 partial 列表中，间接将对象开释回 slub 即可
if (likely(!n)) {
// 解决场景 1
if (new.frozen && !was_frozen) {
// 将 slub 插入到 kmem_cache_cpu 中的 partial 列表中
put_cpu_partial(s, page, 1);
stat(s, CPU_PARTIAL_FREE);
}
// 解决场景 2，因为之前曾经通过 set_freepointer 将对象开释回 slub 了，这里只须要记录 slub 状态即可
if (was_frozen)
stat(s, FREE_FROZEN);
return;
}
// 后续的逻辑就是解决须要将 slub 放入 kmem_cache_node 中的 partial 列表的情景
// 在将 slub 放入 node 缓存之前，须要判断 node 缓存的 nr_partial 是否超过了指定阈值 min_partial（位于 kmem_cache 构造）// nr_partial 示意 kmem_cache_node 中 partial 列表中缓存的 slub 个数
// min_partial 示意 slab cache 规定 kmem_cache_node 中 partial 列表能够包容的 slub 最大个数
// 如果 nr_partial 超过了最大阈值 min_partial，则不能放入 kmem_cache_node 里
if (unlikely(!new.inuse && n->nr_partial >= s->min_partial))
// 如果 slub 变为了一个 empty slub 并且 nr_partial 超过了最大阈值 min_partial
// 跳转到 slab_empty 分支，将 slub 开释回搭档零碎中
goto slab_empty;
// 如果 cpu 本地缓存中没有配置 partial 列表并且 slub 刚刚从 full slub 变为 partial slub
// 则将 slub 插入到 kmem_cache_node 中
if (!kmem_cache_has_cpu_partial(s) && unlikely(!prior)) {remove_full(s, n, page);
add_partial(n, page, DEACTIVATE_TO_TAIL);
stat(s, FREE_ADD_PARTIAL);
}
spin_unlock_irqrestore(&n->list_lock, flags);
// 剩下的状况均属于 slub 原来就在 kmem_cache_node 中的 partial 列表中
// 间接将对象开释回 slub 即可，无需扭转 slub 的地位，间接返回
return;
slab_empty:
// 该分支解决的场景是：slub 太多了，将 empty slub 开释会搭档零碎
// 首先将 slub 从对应的治理链表上删除
if (prior) {
/*
* Slab on the partial list.
*/
remove_partial(n, page);
stat(s, FREE_REMOVE_PARTIAL);
} else {
/* Slab must be on the full list */
remove_full(s, n, page);
}
spin_unlock_irqrestore(&n->list_lock, flags);
stat(s, FREE_SLAB);
// 开释 slub 回搭档零碎，底层调用 __free_pages 将 slub 所治理的所有 page 开释回搭档零碎
discard_slab(s, page);
}3.1 间接开释对象回 slab，调整 slab 相干属性
static void __slab_free(struct kmem_cache *s, struct page *page,
void *head, void *tail, int cnt,
unsigned long addr)
{
// 后续会对 slub 对应的 page 构造相干属性进行批改
// 批改后的属性会长期保留在 new 中，前面通过 cas 替换
struct page new;
....... 省略 ..........
do {
prior = page->freelist;
counters = page->counters;
// 将对象间接开释回 slab 中，调整 slab 的 freelist 指针，以及对象的 freepointer 指针
set_freepointer(s, tail, prior);
new.counters = counters;
// 获取原来 slub 中的 frozen 状态，是否在 cpu 缓存 partial 中
was_frozen = new.frozen;
// inuse 示意 slub 曾经调配进来的对象个数，这里是开释 cnt 个对象，所以 inuse 要减去 cnt
new.inuse -= cnt;
....... 省略 ..........
// cas 更新 slub 中的 freelist
} while (!cmpxchg_double_slab(s, page,
prior, counters,
head, new.counters,
"__slab_free"));
. ...... 省略 ..........
}这一部分的逻辑比较简单，在 __slab_free 内存开释流程的开始，内核不管三七二十一，首先会将对象间接开释回其所在的 slab 中。
当对象被开释回 slab 中之后，slab 构造中的相应属于就须要做出相应的调整，比方：
- 调整 page 构造中的 freelist，它须要指向刚刚被开释的对象。
- 调整 page 构造中的 inuse，inuse 示意 slab 中曾经被调配进来的对象个数，此时对象曾经开释回 slab 中，须要调整 inuse 字段。
- 后续内核会依据不同状况，调整 page 构造的 frozen 属性。
内核会定义一个新的 page 构造 new，将原有 slab 的 page 构造须要更新的上述属性的新值，先一一复制给 new 的对应属性，最初通过 cmpxchg_double_slab 原子更新 slab 对应的属性。
struct page {
struct { /* slub 相干字段 */
........ 省略 .........
// 指向 page 所属的 slab cache
struct kmem_cache *slab_cache;
// 指向 slab 中第一个闲暇对象
void *freelist; /* first free object */
union {
unsigned long counters;
struct { /* SLUB */
// slab 中曾经调配进来的对象
unsigned inuse:16;
// slab 中蕴含的对象总数
unsigned objects:15;
// 该 slab 是否在对应 slab cache 的本地 CPU 缓存中
// frozen = 1 示意缓存再本地 cpu 缓存中
unsigned frozen:1;
};
};
};
}依照失常的更新套路来说，咱们在更新原有 slab 构造中的 freelist，inuse，frozen 这三个属性之前，首先须要将原有 slab 的这三个旧的属性值一一赋值到长期构造 new page 中， 而后在 slab 构造旧值的根底上调整着三个属性的新值 ，最初通过 cmpxchg_double_slab 将这三个属性的新值原子地更新回 slab 中。
然而咱们查看 __slab_free 的代码发现，内核并不是这样操作的，内核只是将原有 slab 的 counter 属性赋值给 new page，而原有 slab 中的 frozen，inuse 属性并没有赋值过来。
此时 new page 构造中的 frozen，inuse 属性仍然是上述 struct page 构造中展现的初始值。
而内核后续的操作就更加奇怪了，间接应用 new.frozen 来判断原有 slab 是否在 slab cache 本地 cpu 的 partial 链表中，间接把 new.inuse 属性当做原有 slab 中曾经调配进来对象的个数。
而 new.frozen，new.inuse 是 page 构造初始状态的值，并不是原有 slab 构造中的值，这样做必定不对啊，难道是内核的一个 bug ?
其实并不是，这是内核十分骚的一个操作，这一点对于 Java 程序员来说很难了解。咱们在认真看一下 struct page 构造，就会发现 counter 属性和 inuse，frozen 属性被定义在一个 union 构造体中。
union 构造体中定义的字段全副共享一片内存，union 构造体的内存占用由其中最大的属性决定。而 struct 构造体中的每个字段都是独占一片内存的。
因为 union 构造体中各个字段都是共享一块内存，所以一个字段的扭转就会影响其余字段的值，从另一方面来看，通过一个字段就能够将整个 union 构造占用的内存块拿进去。明确这些，咱们在回头来看内核的操作。
struct page {
union {
unsigned long counters;
struct { /* SLUB */
// slab 中曾经调配进来的对象
unsigned inuse:16;
// slab 中蕴含的对象总数
unsigned objects:15;
// 该 slab 是否在对应 slab cache 的本地 CPU 缓存中
// frozen = 1 示意缓存再本地 cpu 缓存中
unsigned frozen:1;
};
};
}page 构造中的 counters 是和 inuse，frozen 共用同一块内存的，内核在 __slab_free 中将原有 slab 的 counters 属性赋值给 new.counters 的一瞬间，counters 所在的内存块也就赋值到 new page 的 union 构造中了。
而 inuse，frozen 属性的值也在这个内存块中，所以原有 slab 中的 inuse，frozen 属性也就跟着一起赋值到 new page 的对应属性中了。这样一来，后续的逻辑解决也就通顺了。
counters = page->counters;
new.counters = counters;
// 获取原来 slub 中的 frozen 状态，是否在 cpu 缓存 partial 中
was_frozen = new.frozen;
// inuse 示意 slub 曾经调配进来的对象个数，这里是开释 cnt 个对象，所以 inuse 要减去 cnt
new.inuse -= cnt;同样的情理，咱们再来看内核 cmpxchg_double_slab 中的更新操作：
内核明明在 do .... while 循环中更新了 freelist，inuse，frozen 这三个属性，而 counters 属性只是读取并没有更新操作，那么为什么在 cmpxchg_double_slab 只是更新 page 构造的 freelist 和 counters 呢？inuse，frozen 这两个属性又在哪里更新的呢？
do {
....... 省略 ..........
// cas 更新 slub 中的 freelist
} while (!cmpxchg_double_slab(s, page,
prior, counters,
head, new.counters,
"__slab_free"));我想大家当初肯定可能解释这个问题了，因为 counters，inuse，frozen 共用一块内存，当 inuse，frozen 的值发生变化之后，尽管 counters 的值没有发生变化，然而咱们能够通过更新 counters 来将原有 slab 中的这块内存一起更新掉，这样 inuse，frozen 的值也跟着被更新了。
因为 page 的 freelist 指针在 union 构造体之外，所以须要在 cmpxchg_double_slab 中独自更新。
笔者已经为了想给大家解释分明 page->counters 这个属性的作用，而翻遍了 slab 的所有源码，发现内核源码中对于 page->counters 的应用都是只做简略的读取，并不做扭转，而后间接在更新，这个问题也困扰了笔者很久。
直到为大家写这篇文章的时候，才顿悟。原来 page->counters 的作用只是为了指向 inuse，frozen 所在的内存，不便在 cmpxchg_double_slab 中同时原子地更新这两个属性。
接下来的内容就到了 slab cache 回收内存最为简单的环节了，大家须要多一些急躁，持续跟着笔者的思路走上来，咱们一起来看下内核如何解决三种内存慢速开释的场景。
3.2 开释对象所属 slab 原本就在 cpu 缓存 partial 链表中
was_frozen 指向开释对象所属 slab 构造中的 frozen 属性，用来示意 slab 是否在 slab cache 的本地 cpu 缓存 partial 链表中。
was_frozen = new.frozen; 如果 was_frozen == true 示意开释对象所属 slab 原本就在 kmem_cache_cpu->partial 链表中，内核将对象间接开释回 slab 中，slab 的原有地位不做扭转。
上面咱们看下 was_frozen == fasle 也就是 slab 不在 kmem_cache_cpu->partial 链表中 的时候，内核又是如何解决的？
3.3 开释对象所属 slab 从 full slab 变为了 partial slab
如果开释对象所属 slab 原来是一个 full slab，恰好阐明该 slab 领有比拟好的局部性，过程常常从该 slab 中调配对象，slab 非常沉闷，才导致它变为了一个 full slab
prior = page->freelist = null随着对象的开释，该 slab 从一个 full slab 变为了 partial slab，内核为了更好的利用该 slab 的局部性，所以须要将该 slab 插入到 slab cache 的本地 cpu 缓存 kmem_cache_cpu->partial 链表中。
if (kmem_cache_has_cpu_partial(s) && !prior) {new.frozen = 1;}
if (new.frozen && !was_frozen) {
// 将 slub 插入到 kmem_cache_cpu 中的 partial 列表中
put_cpu_partial(s, page, 1);
stat(s, CPU_PARTIAL_FREE);
}
将 slab 插入到 kmem_cache_cpu->partial 链表的逻辑封装在 put_cpu_partial 中，put_cpu_partial 函数最重要的一个考量逻辑是须要确保 kmem_cache_cpu->partial 链表中所有 slab 中蕴含的闲暇对象总数不能超过 kmem_cache->cpu_partial 的限度。
struct kmem_cache {
// 限定 slab cache 在每个 cpu 本地缓存 partial 链表中所有 slab 中闲暇对象的总数
unsigned int cpu_partial;
};在开释对象所在的 slab 插入到 kmem_cache_cpu->partial 链表之前，put_cpu_partial 函数须要判断以后 kmem_cache_cpu->partial 链表中蕴含的闲暇对象总数 pobjects 是否超过了 kmem_cache->cpu_partial 的限度。
如果超过了，则须要先将以后 kmem_cache_cpu->partial 链表中所有的 slab 转移到其对应的 NUMA 节点缓存 kmem_cache_node->partial 链表中。转移实现之后，在将开释对象所属的 slab 插入到 kmem_cache_cpu->partial 链表中。
static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain)
{
// 只有配置了 CONFIG_SLUB_CPU_PARTIAL 选项，kmem_cache_cpu 中才有会 partial 列表
#ifdef CONFIG_SLUB_CPU_PARTIAL
// 指向原有 kmem_cache_cpu 中的 partial 列表
struct page *oldpage;
// slub 所在治理列表中的 slub 个数，这里的列表是指 partial 列表
int pages;
// slub 所在治理列表中的蕴含的闲暇对象总数，这里的列表是指 partial 列表
// 内核会将列表总体的信息寄存在列表首页 page 的相干字段中
int pobjects;
// 禁止抢占
preempt_disable();
do {
pages = 0;
pobjects = 0;
// 获取 slab cache 中原有的 cpu 本地缓存 partial 列表首页
oldpage = this_cpu_read(s->cpu_slab->partial);
// 如果 partial 列表不为空，则须要判断 partial 列表中所有 slub 蕴含的闲暇对象总数是否超过了 s->cpu_partial 规定的阈值
// 超过 s->cpu_partial 则须要将 kmem_cache_cpu->partial 列表中原有的所有 slub 转移到 kmem_cache_node-> partial 列表中
// 转移之后，再把以后 slub 插入到 kmem_cache_cpu->partial 列表中
// 如果没有超过 s->cpu_partial，则无需转移直接插入
if (oldpage) {
// 从 partial 列表首页中获取列表中蕴含的闲暇对象总数
pobjects = oldpage->pobjects;
// 从 partial 列表首页中获取列表中蕴含的 slub 总数
pages = oldpage->pages;
if (drain && pobjects > s->cpu_partial) {
unsigned long flags;
// 敞开中断，避免并发拜访
local_irq_save(flags);
// partial 列表中所蕴含的闲暇对象总数 pobjects 超过了 s->cpu_partial 规定的阈值
// 则须要将现有 partial 列表中的所有 slub 转移到相应的 kmem_cache_node->partial 列表中
unfreeze_partials(s, this_cpu_ptr(s->cpu_slab));
// 复原中断
local_irq_restore(flags);
// 重置 partial 列表
oldpage = NULL;
pobjects = 0;
pages = 0;
stat(s, CPU_PARTIAL_DRAIN);
}
}
// 无论 kmem_cache_cpu-> partial 列表中的 slub 是否须要转移
// 开释对象所在的 slub 都须要填加到 kmem_cache_cpu-> partial 列表中
pages++;
pobjects += page->objects - page->inuse;
page->pages = pages;
page->pobjects = pobjects;
page->next = oldpage;
// 通过 cas 将 slub 插入到 partial 列表的头部
} while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page)
!= oldpage);
// s->cpu_partial = 0 示意 kmem_cache_cpu->partial 列表不能寄存 slub
// 将开释对象所在的 slub 转移到 kmem_cache_node-> partial 列表中
if (unlikely(!s->cpu_partial)) {
unsigned long flags;
local_irq_save(flags);
unfreeze_partials(s, this_cpu_ptr(s->cpu_slab));
local_irq_restore(flags);
}
preempt_enable();
#endif /* CONFIG_SLUB_CPU_PARTIAL */
}那么咱们如何晓得 kmem_cache_cpu->partial 链表所蕴含的闲暇对象总数到底是多少呢？
这就用到了 struct page 构造中的两个重要属性：
struct page {
// slab 所在链表中的蕴含的 slab 总数
int pages;
// slab 所在链表中蕴含的对象总数
int pobjects;
}咱们都晓得 slab 在内核中的数据结构用 struct page 中的相干构造体示意，slab 在 slab cache 架构中个别是由 kmem_cache_cpu->partial 链表和 kmem_cache_node->partial 链表来组织治理。
那么咱们如何晓得 partial 链表中蕴含多少个 slab？蕴含多少个闲暇对象呢？
答案是内核会将 parital 链表中的这些总体统计信息存储在链表首个 slab 构造中。也就是说存储在首个 page 构造中的 pages 属性和 pobjects 属性中。
在 put_cpu_partial 函数的开始，内核间接获取 parital 链表的首个 slab —— oldpage，并通过 oldpage->pobjects 与 s->cpu_partial 比拟，来判断以后 kmem_cache_cpu->partial 链表中蕴含的闲暇对象总数是否超过了 kmem_cache 构造中规定的 cpu_partial 阈值。
如果超过了，则通过 unfreeze_partials 转移 kmem_cache_cpu->partial 链表中的所有 slab 到对应的 kmem_cache_node->partial 链表中。
既然 kmem_cache_cpu->partial 链表有容量的限度，那么同样 kmem_cache_node->partial 链表中的容量也会有限度。
kmem_cache_node->partial 链表中所蕴含 slab 个数的下限由 kmem_cache 构造中的 min_partial 属性决定。
struct kmem_cache {
// slab cache 在 numa node 中缓存的 slab 个数下限，slab 个数超过该值，闲暇的 empty slab 则会被回收至搭档零碎
unsigned long min_partial;
} 如果以后要转移的 slab 是一个 empty slab，并且此时 kmem_cache_node->partial 链表所蕴含的 slab 个数 kmem_cache_node->nr_partial 曾经超过了 kmem_cache-> min_partial 的限度，那么内核就会间接将这个 empty slab 开释回搭档零碎中。
// 将 kmem_cache_cpu->partial 列表中蕴含的 slub unfreeze
// 并转移到对应的 kmem_cache_node->partial 列表中
static void unfreeze_partials(struct kmem_cache *s,
struct kmem_cache_cpu *c)
{
#ifdef CONFIG_SLUB_CPU_PARTIAL
struct kmem_cache_node *n = NULL, *n2 = NULL;
struct page *page, *discard_page = NULL;
// 挨个遍历 kmem_cache_cpu->partial 列表，将列表中的 slub 转移到对应 kmem_cache_node->partial 列表中
while ((page = c->partial)) {
struct page new;
struct page old;
// 将以后遍历到的 slub 从 kmem_cache_cpu->partial 列表摘下
c->partial = page->next;
// 获取以后 slub 所在的 numa 节点对应的 kmem_cache_node 缓存
n2 = get_node(s, page_to_nid(page));
// 如果和上一个转移的 slub 所在的 numa 节点不一样
// 则须要开释上一个 numa 节点的 list_lock，并对以后 numa 节点的 list_lock 加锁
if (n != n2) {if (n)
spin_unlock(&n->list_lock);
n = n2;
spin_lock(&n->list_lock);
}
do {
old.freelist = page->freelist;
old.counters = page->counters;
VM_BUG_ON(!old.frozen);
new.counters = old.counters;
new.freelist = old.freelist;
// unfrozen 以后 slub，因为行将被转移到对应的 kmem_cache_node->partial 列表
new.frozen = 0;
// cas 更新以后 slub 的 freelist，frozen 属性
} while (!__cmpxchg_double_slab(s, page,
old.freelist, old.counters,
new.freelist, new.counters,
"unfreezing slab"));
// 因为 kmem_cache_node->partial 列表中所蕴含的 slub 个数是受 s->min_partial 阈值限度的
// 所以这里还须要查看 nr_partial 是否超过了 min_partial
// 如果以后被转移的 slub 是一个 empty slub 并且 nr_partial 超过了 min_partial 的限度，则须要将 slub 开释回搭档零碎中
if (unlikely(!new.inuse && n->nr_partial >= s->min_partial)) {
// discard_page 用于将须要开释回搭档零碎的 slub 串联起来
// 后续对立将 discard_page 链表中的 slub 开释回搭档零碎
page->next = discard_page;
discard_page = page;
} else {
// 其余状况，只有 slub 不为 empty，不论 nr_partial 是否超过了 min_partial
// 都须要将 slub 转移到对应 kmem_cache_node->partial 列表的开端
add_partial(n, page, DEACTIVATE_TO_TAIL);
stat(s, FREE_ADD_PARTIAL);
}
}
if (n)
spin_unlock(&n->list_lock);
// 将 discard_page 链表中的 slub 对立开释回搭档零碎
while (discard_page) {
page = discard_page;
discard_page = discard_page->next;
stat(s, DEACTIVATE_EMPTY);
// 底层调用 __free_pages 将 slub 所治理的所有 page 开释回搭档零碎
discard_slab(s, page);
stat(s, FREE_SLAB);
}
#endif /* CONFIG_SLUB_CPU_PARTIAL */
}3.4 开释对象所属 slab 从 partial slab 变为了 empty slab
如果开释对象所在的 slab 原来是一个 partial slab，因为对象的开释刚好变成了一个 empty slab，恰好阐明该 slab 并不是一个沉闷的 slab，它的局部性不好，内核曾经良久没有从该 slab 中调配对象了，所以内核抉择刀枪入库，马放南山。将它开释回 kmem_cache_node->partial 链表中作为本地 cpu 缓存的后备选项。
在将这个 empty slab 插入到 kmem_cache_node->partial 链表之前，同样须要查看以后 partial 链表中的容量 kmem_cache_node->nr_partial 不能超过 kmem_cache-> min_partial 的限度。如果超过限度了，间接将这个 empty slab 开释回搭档零碎中。
if ((!new.inuse || !prior) && !was_frozen) {if (kmem_cache_has_cpu_partial(s) && !prior) {new.frozen = 1;} else {
// !new.inuse 示意以后 slab 刚刚从一个 partial slab 变为了 empty slab
n = get_node(s, page_to_nid(page));
spin_lock_irqsave(&n->list_lock, flags);
}
}
if (unlikely(!new.inuse && n->nr_partial >= s->min_partial))
// 如果 slub 变为了一个 empty slub 并且 nr_partial 超过了最大阈值 min_partial
// 跳转到 slab_empty 分支，将 slub 开释回搭档零碎中
goto slab_empty;开释对象所属的 slab 原本就在 kmem_cache_node->partial 链表中，这种状况下就是间接开释对象回 slab 中，无需扭转 slab 的地位。
4. slab cache 的销毁
终于到了本文最初一个大节了，slab cache 最为简单的内容咱们曾经踏过来了，本大节的内容将会十分的轻松愉悦，这一次笔者来为大家介绍一下 slab cache 的销毁过程。
slab cache 的销毁过程刚刚好和 slab cache 的创立过程相同，笔者在《从内核源码看 slab 内存池的创立初始化流程》的内容中，通过一步一步的源码演示，最终勾画出 slab cache 的残缺架构：
slab cache 销毁的外围步骤如下：
- 首先须要开释 slab cache 在所有 cpu 中的缓存 kmem_cache_cpu 中占用的资源，包含被 cpu 缓存的 slab (kmem_cache_cpu->page)，以及 kmem_cache_cpu->partial 链表中缓存的所有 slab，将它们通通偿还到搭档零碎中。
- 开释 slab cache 在所有 NUMA 节点中的缓存 kmem_cache_node 占用的资源，也就是将 kmem_cache_node->partial 链表中缓存的所有 slab，通通开释回搭档零碎中。
- 在 sys 文件系统中移除
/sys/kernel/slab/<cacchename>节点相干信息。 - 从 slab cache 的全局列表中删除该 slab cache。
- 开释 kmem_cache_cpu 构造，kmem_cache_node 构造，kmem_cache 构造。开释对象的过程就是《1. slab cache 如何回收内存》大节中介绍的内容。
上面咱们一起到内核源码中看一下具体的销毁过程：
void kmem_cache_destroy(struct kmem_cache *s)
{
int err;
if (unlikely(!s))
return;
// 获取 cpu_hotplug_lock，避免 cpu 热插拔扭转 online cpu map
get_online_cpus();
// 获取 mem_hotplug_lock，避免拜访内存的时候进行内存热插拔
get_online_mems();
// 获取 slab cache 链表的全局互斥锁
mutex_lock(&slab_mutex);
// 将 slab cache 的援用技术减 1
s->refcount--;
// 判断 slab cache 是否还存在其余中央的援用
if (s->refcount)
// 如果该 slab cache 还存在援用，则不能销毁，跳转到 out_unlock 分支
goto out_unlock;
// 销毁 memory cgroup 相干的 cache，这里不是本文重点
err = shutdown_memcg_caches(s);
if (!err)
// slab cache 销毁的外围函数，销毁逻辑就封装在这里
err = shutdown_cache(s);
if (err) {
pr_err("kmem_cache_destroy %s: Slab cache still has objects\n",
s->name);
dump_stack();}
out_unlock:
// 开释相干的自旋锁和信号量
mutex_unlock(&slab_mutex);
put_online_mems();
put_online_cpus();}在开始正式销毁 slab cache 之前，首先须要将 slab cache 的援用计数 refcount 减 1。并须要判断 slab cache 是否还存在其余中央的援用。
slab cache 这里在其余中央存在援用的可能性，相干细节笔者在《从内核源码看 slab 内存池的创立初始化流程》一文中的”1. __kmem_cache_alias“大节的内容中曾经具体介绍过了。
当咱们利用 kmem_cache_create 创立 slab cache 的时候，内核会查看以后零碎中是否存在一个各项参数和咱们要创立 slab cache 参数差不多的一个 slab cache，如果存在，那么内核就不会再持续创立新的 slab cache，而是复用已有的 slab cache。
一个能够被复用的 slab cache 须要满足以下四个条件：
- 指定的 slab_flags_t 雷同。
- 指定对象的 object size 要小于等于已有 slab cache 中的对象 size（kmem_cache->size）。
- 如果指定对象的 object size 与已有 kmem_cache->size 不雷同，那么它们之间的差值须要再一个 word size 之内。
- 已有 slab cache 中的 slab 对象对齐 align（kmem_cache->align）要大于等于指定的 align 并且能够整除 align。。
随后会在 sys 文件系统中为复用 slab cache 起一个别名 alias 并创立一个 /sys/kernel/slab/aliasname 目录，然而该目录下的文件须要软链接到原有 slab cache 在 sys 文件系统对应目录下的文件。这里的 aliasname 就是咱们通过 kmem_cache_create 指定的 slab cache 名称。
在这种状况，零碎中的 slab cache 就可能在多个中央产生援用，所以在销毁的时候须要判断这一点。
如果存在其余中央的援用，则须要进行销毁流程，如果没有其余中央的援用，则调用 shutdown_cache 开始正式的销毁流程。
static int shutdown_cache(struct kmem_cache *s)
{
// 这里会开释 slab cache 占用的所有资源
if (__kmem_cache_shutdown(s) != 0)
return -EBUSY;
// 从 slab cache 的全局列表中删除该 slab cache
list_del(&s->list);
// 开释 sys 文件系统中移除 /sys/kernel/slab/name 节点的相干资源
sysfs_slab_unlink(s);
sysfs_slab_release(s);
// 开释 kmem_cache_cpu 构造
// 开释 kmem_cache_node 构造
// 开释 kmem_cache 构造
slab_kmem_cache_release(s);
}
return 0;
}4.1 开释 slab cache 占用的所有资源
- 首先须要开释 slab cache 在所有 cpu 中的缓存 kmem_cache_cpu 中占用的资源，包含被 cpu 缓存的 slab (kmem_cache_cpu->page)，以及 kmem_cache_cpu->partial 链表中缓存的所有 slab，将它们通通偿还到搭档零碎中。
- 开释 slab cache 在所有 NUMA 节点中的缓存 kmem_cache_node 占用的资源，也就是将 kmem_cache_node->partial 链表中缓存的所有 slab，通通开释回搭档零碎中。
- 在 sys 文件系统中移除
/sys/kernel/slab/<cacchename>节点相干信息。
/*
* Release all resources used by a slab cache.
*/
int __kmem_cache_shutdown(struct kmem_cache *s)
{
int node;
struct kmem_cache_node *n;
// 开释 slab cache 本地 cpu 缓存 kmem_cache_cpu 中缓存的 slub 以及 partial 列表中的 slub，通通归还给搭档零碎
flush_all(s);
// 开释 slab cache 中 numa 节点缓存 kmem_cache_node 中 partial 列表上的所有 slub
for_each_kmem_cache_node(s, node, n) {free_partial(s, n);
if (n->nr_partial || slabs_node(s, node))
return 1;
}
// 在 sys 文件系统中移除 /sys/kernel/slab/name 节点相干信息
sysfs_slab_remove(s);
return 0;
}4.2 开释 slab cache 在各个 cpu 中的缓存资源
内核通过 on_each_cpu_cond 挨个遍历所有 cpu，在遍历的过程中通过 has_cpu_slab 判断 slab cache 是否在该 cpu 中还占有缓存资源，如果是则调用 flush_cpu_slab 将缓存资源开释回搭档零碎中。
// 开释 kmem_cache_cpu 中占用的所有内存资源
static void flush_all(struct kmem_cache *s)
{
// 遍历每个 cpu，通过 has_cpu_slab 函数查看 cpu 上是否还有 slab cache 的相干缓存资源
// 如果有，则调用 flush_cpu_slab 进行资源的开释
on_each_cpu_cond(has_cpu_slab, flush_cpu_slab, s, 1, GFP_ATOMIC);
}
static bool has_cpu_slab(int cpu, void *info)
{
struct kmem_cache *s = info;
// 获取 cpu 在 slab cache 上的本地缓存
struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu);
// 判断 cpu 本地缓存中是否还有缓存的 slub
return c->page || slub_percpu_partial(c);
}
static void flush_cpu_slab(void *d)
{
struct kmem_cache *s = d;
// 开释 slab cache 在 cpu 上的本地缓存资源
__flush_cpu_slab(s, smp_processor_id());
}
static inline void __flush_cpu_slab(struct kmem_cache *s, int cpu)
{struct kmem_cache_cpu *c = per_cpu_ptr(s->cpu_slab, cpu);
if (c->page)
// 开释 cpu 本地缓存的 slub 到搭档零碎
flush_slab(s, c);
// 将 cpu 本地缓存中的 partial 列表里的 slub 全副开释回搭档零碎
unfreeze_partials(s, c);
}4.3 开释 slab cache 的外围数据结构
这里的开释流程正是笔者在本文《1. slab cache 如何回收内存》大节中介绍的内容。
void slab_kmem_cache_release(struct kmem_cache *s)
{
// 开释 slab cache 中的 kmem_cache_cpu 构造以及 kmem_cache_node 构造
__kmem_cache_release(s);
// 最初开释 slab cache 的外围数据结构 kmem_cache
kmem_cache_free(kmem_cache, s);
}总结
整个 slab cache 系列篇幅十分宏大，波及到的细节十分丰盛，为了不便大家回顾，笔者这里将 slab cache 系列波及到的重点内容再次梳理总结一下。
- 《细节拉满，80 张图带你一步一步推演 slab 内存池的设计与实现》
- 《从内核源码看 slab 内存池的创立初始化流程》
- 《深刻了解 slab cache 内存调配全链路实现》
在本文正式进入 slab 相干内容之后，笔者首先为大家具体介绍了 slab 内存池中对象的内存布局状况，如下图所示：
在此基础之上，咱们持续采纳一步一图的形式，一步一步推演出 slab 内存池的整体架构，如下图所示：
随后基于此架构，笔者介绍了在不同场景下 slab 内存池分配内存以及回收内存的外围原理。在交代完外围原理之后，咱们进一步深刻到内核源码实现中来一一验证。
在内核源码章节的开始，笔者首先为大家介绍了 slab 内存池的创立流程，流程图如下：
在 slab 内存池创立进去之后，随后笔者又深刻介绍了 slab 内存池如何分配内存块的相干源码实现，其中具体介绍了在多种不同场景下，内核如何解决内存块的调配。
在咱们革除了 slab 内存池如何分配内存块的源码实现之后，紧接着笔者又介绍了 slab 内存池如何进行内存块的回收，回收过程要比调配过程简单很多，同样也波及到多种简单场景的解决：
最初笔者介绍了 slab 内存池的销毁过程：
好了，整个 slab cache 相干的内容到此就完结了，感激大家的收看，咱们下篇文章见~~~