
深度解析 slab 内存池回收内存以及销毁全流程
在上篇文章 《深入理解 slab cache 内存分配全链路实现》 中,笔者详细地为大家介绍了 slab cache 进行内存分配的整个链路实现,本文我们就来到了 slab cache 最后的一部分内容了,当申请的内存使用完毕之后,下面就该释放内存了。
在接下来的内容中,笔者为大家介绍一下内核是如何将内存块释放回 slab cache 的。我们还是先从 slab cache 释放内存的内核 API 开始聊起~~~
内核提供了 kmem_cache_free 函数,用于将对象释放回其所属的 slab cache 中,参数 x 表示我们要释放的内存块(对象)的虚拟内存地址,参数 s 指向内存块所属的 slab cache。
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 函数的作用即可。
virt_to_cache 函数首先会通过释放对象的虚拟内存地址找到其所在的物理内存页 page,然后通过 struct page 结构中的 slab_cache 指针找到 page 所属的 slab cache。
2. slab cache 在快速路径下回收内存
slab cache 回收内存相关的逻辑封装在 do_slab_free 函数中:
- 参数 kmem_cache *s 表示释放对象所在的 slab cache,指定我们要将对象释放到哪里。
- 参数 page 表示释放对象所在的 slab,slab 在内核中使用 struct page 结构来表示。
- 参数 head 指向释放对象的虚拟内存地址(起始内存地址)。
- 该函数支持向 slab cache 批量的释放多个对象,参数 tail 指向批量释放对象中最后一个对象的虚拟内存地址。
- 参数 cnt 表示释放对象的个数,也是用于批量释放对象
- 参数 addr 用于 slab 调试,这里我们不需要关心。
slab cache 针对内存的回收流程其实和我们在上一小节 《11. slab cache 如何分配内存》介绍的 slab cache 内存分配流程是相似的。
内存回收总体也是分为快速路径 fastpath 和慢速路径 slow path,在 do_slab_free 函数中内核会首先尝试 fastpath 的回收流程。
如果释放对象所在的 slab 刚好是 slab cache 在本地 cpu 缓存 kmem_cache_cpu->page 缓存的 slab,那么内核就会直接将对象释放回缓存 slab 中。
既然是快速路径释放,那么在 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 架构中的位置。
下面笔者会带大家一一梳理这些场景,我们一起来看一下内核在这些不同场景中到底是如何处理的?
在开始阅读本小节的内容之前,建议大家先回顾下本文 《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 的位置不做任何改变。
下面我们就到内核的源码实现中,来一一验证这四种慢速释放场景。
3.1 直接释放对象回 slab,调整 slab 相关属性
这一部分的逻辑比较简单,在 __slab_free 内存释放流程的开始,内核不管三七二十一,首先会将对象直接释放回其所在的 slab 中。
当对象被释放回 slab 中之后,slab 结构中的相应属于就需要做出相应的调整,比如:
- 调整 page 结构中的 freelist,它需要指向刚刚被释放的对象。
- 调整 page 结构中的 inuse,inuse 表示 slab 中已经被分配出去的对象个数,此时对象已经释放回 slab 中,需要调整 inuse 字段。
- 后续内核会根据不同情况,调整 page 结构的 frozen 属性。
内核会定义一个新的 page 结构 new
,将原有 slab 的 page 结构需要更新的上述属性的新值,先一一复制给 new 的对应属性,最后通过 cmpxchg_double_slab 原子更新 slab 对应的属性。
按照正常的更新套路来说,我们在更新原有 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 结构占用的内存块拿出来。明白这些,我们在回头来看内核的操作。
page 结构中的 counters 是和 inuse,frozen 共用同一块内存的,内核在 __slab_free 中将原有 slab 的 counters 属性赋值给 new.counters 的一瞬间,counters 所在的内存块也就赋值到 new page 的 union 结构中了。
而 inuse,frozen 属性的值也在这个内存块中,所以原有 slab 中的 inuse,frozen 属性也就跟着一起赋值到 new page 的对应属性中了。这样一来,后续的逻辑处理也就通顺了。
同样的道理,我们再来看内核 cmpxchg_double_slab 中的更新操作:
内核明明在 do .... while
循环中更新了 freelist,inuse,frozen 这三个属性,而 counters 属性只是读取并没有更新操作,那么为什么在 cmpxchg_double_slab 只是更新 page 结构的 freelist 和 counters 呢?inuse,frozen 这两个属性又在哪里更新的呢?
我想大家现在一定能够解释这个问题了,由于 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 == 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
随着对象的释放,该 slab 从一个 full slab 变为了 partial slab,内核为了更好的利用该 slab 的局部性,所以需要将该 slab 插入到 slab cache 的本地 cpu 缓存 kmem_cache_cpu->partial 链表中。
将 slab 插入到 kmem_cache_cpu->partial 链表的逻辑封装在 put_cpu_partial 中,put_cpu_partial 函数最重要的一个考量逻辑是需要确保 kmem_cache_cpu->partial 链表中所有 slab 中包含的空闲对象总数不能超过 kmem_cache->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 链表中。
那么我们如何知道 kmem_cache_cpu->partial 链表所包含的空闲对象总数到底是多少呢?
这就用到了 struct page 结构中的两个重要属性:
我们都知道 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 属性决定。
如果当前要转移的 slab 是一个 empty slab,并且此时 kmem_cache_node->partial 链表所包含的 slab 个数 kmem_cache_node->nr_partial
已经超过了 kmem_cache-> min_partial
的限制,那么内核就会直接将这个 empty slab 释放回伙伴系统中。
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 释放回伙伴系统中。
释放对象所属的 slab 本来就在 kmem_cache_node->partial 链表中,这种情况下就是直接释放对象回 slab 中,无需改变 slab 的位置。
4. slab cache 的销毁
终于到了本文最后一个小节了, slab cache 最为复杂的内容我们已经踏过去了,本小节的内容将会非常的轻松愉悦,这一次笔者来为大家介绍一下 slab cache 的销毁过程。
slab cache 的销毁过程刚刚好和 slab cache 的创建过程相反,笔者在本文 《9. slab cache 是如何被创建出来的》小节的内容中,通过一步一步的源码演示,最终勾勒出 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 结构。释放对象的过程就是 《12. slab cache 如何回收内存》小节中介绍的内容。
下面我们一起到内核源码中看一下具体的销毁过程:
在开始正式销毁 slab cache 之前,首先需要将 slab cache 的引用计数 refcount 减 1。并需要判断 slab cache 是否还存在其他地方的引用。
slab cache 这里在其他地方存在引用的可能性,相关细节笔者在本文 《9.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 开始正式的销毁流程。
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>
节点相关信息。
4.2 释放 slab cache 在各个 cpu 中的缓存资源
内核通过 on_each_cpu_cond 挨个遍历所有 cpu,在遍历的过程中通过 has_cpu_slab 判断 slab cache 是否在该 cpu 中还占有缓存资源,如果是则调用 flush_cpu_slab 将缓存资源释放回伙伴系统中。
4.3 释放 slab cache 的核心数据结构
这里的释放流程正是笔者在本文 《12. slab cache 如何回收内存》小节中介绍的内容。
总结
整个 slab cache 系列篇幅非常庞大,涉及到的细节非常丰富,为了方便大家回顾,笔者这里将 slab cache 系列涉及到的重点内容再次梳理总结一下。
- 《细节拉满,80 张图带你一步一步推演 slab 内存池的设计与实现》
- 《从内核源码看 slab 内存池的创建初始化流程》
- 《深入理解 slab cache 内存分配全链路实现》
在本文正式进入 slab 相关内容之后,笔者首先为大家详细介绍了 slab 内存池中对象的内存布局情况,如下图所示:
在此基础之上,我们继续采用一步一图的方式,一步一步推演出 slab 内存池的整体架构,如下图所示:
随后基于此架构,笔者介绍了在不同场景下 slab 内存池分配内存以及回收内存的核心原理。在交代完核心原理之后,我们进一步深入到内核源码实现中来一一验证。
在内核源码章节的开始,笔者首先为大家介绍了 slab 内存池的创建流程,流程图如下:
在 slab 内存池创建出来之后,随后笔者又深入介绍了 slab 内存池如何分配内存块的相关源码实现,其中详细介绍了在多种不同场景下,内核如何处理内存块的分配。
在我们清除了 slab 内存池如何分配内存块的源码实现之后,紧接着笔者又介绍了 slab 内存池如何进行内存块的回收,回收过程要比分配过程复杂很多,同样也涉及到多种复杂场景的处理:
最后笔者介绍了 slab 内存池的销毁过程:
好了,整个 slab cache 相关的内容到此就结束了,感谢大家的收看,我们下篇文章见~~~
文章转载自公众号:bin的技术小屋
