探秘Linux内存管理：三大分配器的奇妙世界

在 Linux 系统的庞大体系中，内存管理堪称是最为核心的功能之一，就如同心脏对于人体的重要性，它承担着协调和管理计算机内存资源的重任，确保各个应用程序能够在有限的内存空间中高效、稳定地运行。可以毫不夸张地说，优秀的内存管理机制是 Linux 系统高性能、高稳定性的基石。

在深入探讨 Linux 内存管理的核心内容之前，我们先来认识两个最为基础的概念：虚拟内存与物理内存。物理内存是计算机硬件中实实在在用于存储程序和数据的内存芯片，也被称为主存储器，它就像是一个临时的 “数据仓库”，程序运行时的数据和指令都暂时存放在这里。而虚拟内存则是一种相对抽象的概念，它是 Linux 内存管理中的一项关键技术，让每个进程都仿佛拥有一块连续且独立的内存空间，就好像每个进程都有自己专属的 “大仓库”，可以自由地存放数据和代码，而无需担心其他进程的干扰，也无需考虑物理内存的实际限制 。

内存管理的核心任务主要包含以下几个方面：

一、引导内存分配器

linux系统中使用伙伴系统对物理页面进行分配管理，但是伙伴分配系统需要内核完成初始化以及建立相关内核数据结构后才能够正常工作。因此，我们不难看出在内核初始化相关数据结构时需要另一种内存分配器。早期Linux没有较为完善的引导内存分配器，但是随着硬件的发展和日趋复杂，处理不同体系的内存分配代码也渐渐复杂起来，随之就需要引导内存分配器来初始化系统主要内存分配器的数据结构以确保其正常工作。在内核2.3.23版本中bootmem引导内存分配器补丁被加入，使用位图来表示页面使用状况。

然后在内核2.3.48版本时，linux内核移植到IA64时正式使用bootmem作为引导内存分配器。随着时间的流逝，内存检测已经从简单地向BIOS询问扩展内存块的大小演变为处理复杂的表，块，库和群集。这时开始使用memblock作为引导内存分配器。

在bootmem向memblock过渡时，出现nobootmem作为兼容层，提供与bootmem类似api。在内核版本4.17时，在linux所支持的24种架构中，只有5种仍在使用bootmem作为唯一的早期内存分配器，14中将memblock与nobootmem一起使用，其余同时使用memblock和bootmem作为引导内存分配器。

bootmem 的数据结构主要由struct bootmem_data来描述，这个结构体包含了许多关键信息：

1.1引导内存分配器bootmem

首先查看bootmem_data数据结构，表示每个节点物理内存以及其页面使用情况。

首先调用mminit_validate_memmodel_limits()函数检查指定范围物理页面是否有效，然后初始化bootmem_data结构，其中mapstart指向所分配位图页面。link_bootmem()函数是将bootmem_data加入bdata_list链表中。最后将所有位图设为1，即页面目前不可用。

该函数将bootmem_data加入链表，bdata_list中节点顺序是按照起始页面从小到大排列。

该函数中sidx表示所释放起始页面偏移，eidx表示结束页面偏移，循环遍历相应位图将其设为0，则该页面可用。

该函数sidx和eidx表示锁保留页面的范围，如果flags设置BOOTMEM_EXCLUSIVE标志位则表示将指定范围内页面从bootmem中释放。

该函数size表示所需要分配多少字节的内存，align表示分配内存按多少字节对齐，goal表示分配内存最小物理地址，limit表示分配内存最大物理地址。首先对参数进行检验，size不能为空，align必须为2的指数，同时分配内存不能超出范围。

获取bootmem所保留页面范围并重新计算所分配内存起始物理页面。

设置起始和结束索引，如果bootmem上次分配内存页面大于sidx则设置fallback。

首先获取bootmem位图在sidx和eidx范围数个为0的索引，然后在进行对齐获取起始索引并重新计算结束索引，验证是否超出bootmem所拥有页面范围，超出则退出循环分配失败。否则进入for循环在sidx和eidx遍历查看是否存在页面被bootmem保留，如果存在则以此索引为新sidx进行设置，重新遍历，相反则继续进行分配。根据bootmem上次分配内存的偏移设置所分配内存起始物理地址以及结束地址，最后设置这些页面的位图为1，即保留页面。

检查fallback是否为0，如果不为0则返回继续进行查找。

获取bootmem页面范围以及位图。

循环遍历位图释放bootmem未进行保留的页面，即相应位图设为0的页面。

1.2引导内存分配器memblock

随着硬件的发展以及复杂化，内存检测已经从简单地向BIOS询问扩展内存块的大小演变为处理复杂的表，块，库和群集。在x86架构上, 内核启动初期首先使用early_res机制接替BIOS e820的工作, 然后再交给架构独立的bootmem分配器, 最后转由伙伴分配系统进行页面管理。然后有人认为可以去掉bootmem以此简化该过程并提交patch，最终人们提议使用PowerPC, SuperH和SPARC架构上的LMB内存分配器作为系统启动初期的内存分配器。内核数据结构：

该函数idx为type_a和type_b中起始索引组合，nid为寻找内存区域所在节点号，flags为标志位，out_start、out_end和out_nid为输出符合调节的内存区域物理地址范围及所在节点号，type_a为寻找内存区域必须处于其拥有内存范围内，type_b为寻找目标内存不在其拥有内存范围内。函数首先获取type_a和type_b中region数组起始索引，然后循环遍历寻找属于type_a但不属于type_b的首个内存区域。

该函数与__next_mem_range()过程大致一致，只不过遍历方向是从高物理地址向低物理地址遍历。

该函数中size表示寻找物理内存大小(字节)，align为物理内存对齐，start表示所寻找内存区域最小物理地址，end为最大物理地址，nid为节点号，flags为标志位。检查end是否等于MEMBLOCK_ALLOC_ACCESSIBLE，相等则设置end为memblock.current_limit，重新计算所查询物理地址范围。

检查memblock.bottom_up和end>kenel_end是否均为真，即内存查询是否为从低地址项高地址且end高与内核最大虚拟地址所对应的物理地址，重新获取查询范围并进行查询。

最后进行从高地址到低地址进行查询。

该函数会通过for_each_free_mem_range()宏对memblock中进行遍历(由低物理地址到高物理地址)，寻找属于memblock.memory但不属于memblock.reserved且符合添加的物理内存区域。

该函数与__memblock_find_range_bottom_up()工作过程类似，只是遍历方向为高地址到低地址。

该函数base为添加内存起始物理地址，size为添加的物理内存大小(字节数目)，nid为添加内存所在节点号，flasg为添加region标志位。首先计算获取所添加物理内存所在物理地址范围，然后检查memblock_type中region数组是否为空。如果为空则初始化region数组首个元素并返回。

遍历memblock_type所具有的region数组，获取数组中基地址处于base~end之间的元素，如果寻找到并且insert为真则将处于base~rbase之间的内存插入数组中，nr_new表示新插入的元素会增加1，继续遍历。

经过遍历后，检查内存区域是否完全插入，如果有部分区域并未插入则检查insert是否为真，为真则将剩余部分也插入region数组中，否则继续运行。

检查insert是否为真，若为真则将memblock_type中的region数组进行合并，否则检查nr_new+type->cnt是否超出type中region数组最大数，超出则对type中region数组进行扩充，设置insert为真继续重复以上操作。

该函数idx表示插入region数组索引，base表示内存物理起始地址，size表示内存大小(字节数目)。首先获取idx所对应memblock_region指针，再将索引处于idx~type->cnt范围的region元素复制到idx+1~cnt+1所对应数组中，最后进行初始化并增加type相应计数。

该函数遍历type中region数组，将内存区域连续的region合并。

该函数中new_area_start表示向type中添加物理内存区域起始物理地址，new_area_start表示内存区域大小。收件检查是否使用slab缓存以及是否可以扩充type中region数组大小。

获取原region数组大小并将其乘以2作为将要分配region数组大小，按页面对齐并根据type类型获取相应slab缓存使用标志位。

开始分配新region数组内存空间，如果使用slab，则从slab缓存中分配，否则从memblock中分配。

最后复制原来region数组并将剩余空间设为0并释放原数组所在内存空间。

该函数从type中region数组分离指定范围物理内存，base表示分离内存区域起始物理地址，size为分离物理内存大小，start_rgn为输出分离后的内存区域起始region，end_rgn为结束region。如果type中region数组空间不足则扩充region数组。

循环遍历type中region数组，对于处于分离内存区域的region进行分割并重新插入到数组中，最后返回索引。

将type中指定索引region移除数组。

从type移除处于给定范围内物理内存区域。

二、伙伴分配器

当引导内存分配器完成它的使命后，伙伴分配器便接过了管理物理内存的重任，成为 Linux 内存管理中的中流砥柱。伙伴分配器在物理内存分配中占据着基础性的关键地位，它主要负责管理连续的物理内存页，为系统中对大块内存有需求的部分提供支持 。

伙伴分配器的工作原理极具特色，它以 2 的幂次方为单位来管理内存块，将物理内存划分成一系列大小不同的页块（page block）。这里引入了一个重要的概念 —— 阶（order），2^n 个连续的页被称为 n 阶页块，例如，1 个页是 0 阶页块，2 个连续页是 1 阶页块，4 个连续页则是 2 阶页块，以此类推 。

在伙伴分配器的管理体系中，内存块之间存在着一种特殊的 “伙伴关系”。满足以下条件的两个 n 阶页块被称为伙伴：首先，它们的物理地址必须是连续的，就像邻居一样紧紧相邻；其次，页块的第一页的物理页号必须是 2^n 的整数倍，这是一种特定的位置规则；最后，如果将它们合并成（n+1）阶页块，合并后的页块第一页的物理页号必须是 2^(n+1) 的整数倍 。例如，假设一个系统的页大小为 4KB，那么 0 号页和 1 号页（它们组成 1 阶页块，每个页块包含 2 个页，即 8KB）是伙伴，因为它们地址连续，0 号页的页号是 2^0（也就是 1）的整数倍，且它们合并成 2 阶页块（包含 4 个页，16KB）时，第一页 0 号页的页号也是 2^1（即 2）的整数倍 。

当系统需要分配内存时，伙伴分配器会按照一定的策略进行操作。如果请求分配 n 阶页块，它首先会查看是否有空闲的 n 阶页块，如果有，就如同从货架上直接取下一件商品一样，直接将其分配出去；若没有空闲的 n 阶页块，它就会去查看是否存在空闲的（n+1）阶页块。若有，就会将（n+1）阶页块巧妙地分裂为两个 n 阶页块，一个插入空闲 n 阶页块链表，以备后续分配使用，另一个则分配给需要的程序 。如果连（n+1）阶页块也没有空闲的，那就继续查看更高阶的页块，直到找到合适的页块进行分配或者确定无法满足分配需求为止 。

释放内存的过程则是分配的逆过程。当释放一个 n 阶页块时，伙伴分配器会仔细检查它的伙伴是否空闲。如果伙伴不空闲，就将该 n 阶页块插入到空闲的 n 阶页块链表中；如果伙伴空闲，那么就如同将两个相邻的积木块合并成一个更大的积木块一样，将它们合并为 n+1 阶页块，然后再对这个合并后的 n+1 阶页块重复上述释放检查操作，直到不能合并或者已经合并到最大的块为止 。

伙伴分配器在内存管理方面具有显著的优点。由于它将物理内存按照物理页号（PFN）将不同的页放入到不同阶的链表中，根据需要分配内存的大小，能够快速计算出当前分配应该在哪个阶去找空闲的内存块，如果当前阶中没有空闲块，就可以迅速到更高阶的链表中去查找，因此分配效率相较于bootmem的线性扫描位图有了大幅提升 。这种方式就像是在一个精心分类的图书馆中找书，每个书架都按照特定的规则摆放书籍，读者可以快速定位到自己需要的书籍所在的书架区域 。

然而，伙伴分配器也并非完美无缺。在释放内存时，调用方必须记住之前该页分配的阶数，然后释放从该页开始的 2^order 个页，这对于调用者来说是一个不小的负担，容易出错且使用不够便捷 。

另外，由于伙伴分配器每次分配必须是 2^order 个页同时分配，当实际需要的内存大小小于 2^order 时，就会不可避免地造成内存浪费，产生内部碎片 。例如，如果一个程序只需要 5KB 的内存，但伙伴分配器按照规则可能会分配 8KB 的内存块（1 阶页块，假设页大小为 4KB），那么就会有 3KB 的内存被浪费，这在对内存使用效率要求极高的场景下，可能会成为一个制约因素 。

满足以下条件 的两个n阶页块称为伙伴：

2.2伙伴分配器原理

伙伴分配器分配和释放物理页的数量单位为阶。分配n阶页块的过程如下：

上图的buddy分配和回收可以简单叙述成：需要分配内存时如果没有合适的内存块，会对半切分内存块直到分离出合适大小的内存块为止，最后再将其返回。需要释放内存时，会寻找相邻的块，如果其已经释放了，就将这俩合并，再递归这个过程，直到无法再合并为止。

2.2数据结构

分区的伙伴分配器专注于某个内存节点的某个区域。内存区域的结构体成员free_area用来维护空闲页块，数组下标对应页块的阶数。 系统内存中的每个物理内存页（页帧），都对应于一个struct page实例, 每个内存域都关联了一个struct zone的实例，其中保存了用于管理伙伴数据的主要数数组，内核源码结构

struct free_area是一个伙伴系统的辅助数据结构：

伙伴系统的明显缺点是：由于圆整到下一个 2 的幂，很可能造成分配段内的碎片。例如，33KB 的内存请求只能使用 64KB 段来满足。事实上，我们不能保证因内部碎片而浪费的单元一定少于 50%。

2.3伙伴分配器的优缺点

优点：由于将物理内存按照PFN将不同的page放入到不同order中，根据需要分配内存的大小，计算当前这次分配应该在哪个order中去找空闲的内存块，如果当前order中没有空闲，则到更高阶的order中去查找，因此分配的效率比boot memory的线性扫描bitmap要快很多。

缺点：

伙伴分配器分配和释放物理页的数量单位为阶。分配n阶页块的过程如下：

分区的伙伴分配器专注于某个内存节点的某个区域。内存区域的结构体成员free_area用来维护空闲页块，数组下标对应页块的阶数。

图片

内核源码结构：

内核使用GFP_ZONE_TABLE 定义了区域类型映射表的标志组合，其中GFP_ZONES_SHIFT是区域类型占用的位数，GFP_ZONE_TABLE 把每种标志组合映射到32位整数的某个位置，偏移是（标志组合*区域类型位数），从这个偏移开始的GFP_ZONES_SHIFT个二进制存放区域类型。

备用区域这个东西很重要，但是我现在也不能完完全全的了解他，只知道他可以加快我们申请内存的速度，下面的快速路径会用到他。

如果首选的内存节点或区域不能满足分配请求，可以从备用的内存区域借用物理页。借用必须遵守相应的规则。

借用规则：

内存节点的结构体pg_data_t实例已定义备用区域列表node_zonelists。

2.4伙伴分配器的结构

内核源码如下：

UMA系统只有一个备用区域的列表，按照区域类型从高到低顺序排列。假设UMA系统中包含普通区域和DMA区域，则备用区域列表为:(普通区域、MDA区域)。NUMA系统中每个内存节点有两个备用区域列表:一个包含所有节点的内存区域，另一个仅包含当前节点的内存区域。

ZONELIST_FALLBACK（包含所有内存节点的备用区域）列表有两种排序方法：

a.节点优先顺序

b.区域优先顺序

首选的内存区域什么情况下从备用区域借用物理页呢？每个内存区域有3个水线：

而且每个区域的水位线是初始化的时候通过每个区域的物理页情况计算出来的。计算后存到struct zone的watermark数组中，使用的时候直接通过下面的宏定义获取：

struct zone的数据结构：

最低水线以下的内存称为紧急保留内存，一般用于内存回收，其他情况不可以动用紧急保留内存，在内存严重不足的紧急情况下，给承诺"分给我们少量的紧急保留内存使用，我可以释放更多的内存"的进程使用。

可以通过/proc/zoneinfo看到系统zone的水位线和物理页情况：

2.5伙伴分配器分配过程分析

当向内核请求分配 (2(i-1)，2i]数目的页块时，按照 2^i 页块请求处理。如果对应的页块链表中没有空闲页块，那我们就在更大的页块链表中去找。当分配的页块中有多余的页时，伙伴系统会根据多余的页块大小插入到对应的空闲页块链表中。

例如，要请求一个 128 个页的页块时，先检查 128 个页的页块链表是否有空闲块。如果没有，则查 256 个页的页块链表；如果有空闲块的话，则将 256 个页的页块分成两份，一份使用，一份插入 128 个页的页块链表中。如果还是没有，就查 512 个页的页块链表；如果有的话，就分裂为 128、128、256 三个页块，一个 128 的使用，剩余两个插入对应页块链表。

伙伴分配器进行页分配的时候首先调用alloc_pages，alloc_pages 会调用 alloc_pages_current，alloc_pages_current会调用__alloc_pages_nodemask函数，他是伙伴分配器的核心函数：

上面是alloc_pages的第一个参数分配标志位，表示分配的允许情况，alloc_pages的第二个参数表示分配的阶数：

从伙伴分配器的核心函数__alloc_pages_nodemask可以看到函数主要两部分，一是执行快速分配函数get_page_from_freelist，二是执行慢速分配函数__alloc_pages_slowpath。现在先看快速分配函数get_page_from_freelist：

每一个 zone，都有伙伴系统维护的各种大小的队列，就像上面伙伴系统原理里讲的那样。这里调用 rmqueue 就很好理解了，就是找到合适大小的那个队列，把页面取下来。接下来的调用链是 rmqueue->__rmqueue->__rmqueue_smallest。在这里，我们能清楚看到伙伴系统的逻辑。

从当前的 order，也即指数开始，在伙伴系统的 free_area 找 2^order 大小的页块。如果链表的第一个不为空，就找到了；如果为空，就到更大的 order 的页块链表里面去找。找到以后，除了将页块从链表中取下来，我们还要把多余部分放到其他页块链表里面。expand 就是干这个事情的。area–就是伙伴系统那个表里面的前一项，前一项里面的页块大小是当前项的页块大小除以 2，size 右移一位也就是除以 2，list_add 就是加到链表上，nr_free++ 就是计数加 1。

然后看看慢速分配函数__alloc_pages_slowpath：

alloc_page和__get_free_page都是从Buddy分配页面，只是最终返回值类型不同而已，前者返回page指针，后者返回该page所在的虚拟地址。

两者最终都会调用到核心函数__alloc_pages_nodemas

组合：

三、slab分配器

在 Linux 内存管理的大家庭中，slab 分配器犹如一位贴心的助手，专门负责管理小对象（通常是小于一个页面大小，即小于 4KB 的对象）的内存分配，为系统中众多对小内存有频繁需求的模块提供了高效的支持 。

slab 分配器的设计目标明确，旨在提高内存分配的速度和效率，同时减少内存碎片的产生，并减轻内核内存管理的负担。它通过巧妙的设计，将内核中常用的数据结构和对象分成若干个大小相等的 slab 缓存，每个 slab 缓存就像是一个专门存放特定物品的小仓库，对应一种大小的数据结构或对象 。当系统需要分配内存时，就如同从相应的小仓库中直接取出一块空闲内存，当不需要使用时，又将其放回对应的小仓库，大大提高了内存分配和回收的效率 。

在 Linux 内核中，常见的 slab、slub、slob 这三种分配器虽然都属于 slab 分配器家族，但它们在实现和应用场景上存在着一些差异 。slab 分配器是最早出现的，它将内核中常用的数据结构和对象分成若干个大小相等的 slab 缓存，每个 slab 缓存对应一种大小的数据结构或对象，通过维护空闲对象链表、部分空 slab 链表和已满 slab 链表来管理内存 。

slob 分配器则是一种轻量级的内存分配器，通常用于嵌入式设备，它的代码量较小，实现相对简单，通过维护一个简单的内存块链表来管理内存，在分配内存时使用最新适配算法 。而 slub 分配器是对 slab 分配器的改进，它采用了更加高效的算法，在大型机上表现出色，并且能更好地适应 NUMA 系统，相对于 slab 有 5%-10% 的性能提升和减小 50% 的内存占用 。由于 slub 分配器在现代 Linux 内核中使用最为广泛，下面我们将重点对其进行深入探讨 。

3.1slab核心思想

为每种对象类型创建一个内存缓存，每个内存缓存由多个大块组成，一个大块是一个或多个连续的物理页，每个大块包含多个对象。slab采用面向对象的思想，基于对象类型管理内存，每种对象被划分为一个类，比如进程描述符（task_struct）是一个类，每个进程描述符实现是一个对象。内存缓存组成结构如下：

在 Linux 中，slab 可以处于三种可能状态之一：

slab 分配器首先尝试在部分为空的 slab 中用空闲对象来满足请求。如果不存在，则从空的 slab 中分配空闲对象。如果没有空的 slab 可用，则从连续物理页面分配新的 slab，并将其分配给 cache；从这个 slab 上，再分配对象内存。

3.2slab分配器的作用

slab 分配器由kmem_cache --> kmem_cache_node --> object三个结构相结合地方式来描述，其中cache由 struct kmem_cache来描述，struct kmem_cache.中的成员struct kmem_cache_node，lists数组包含三个slab list:full,part,free, 这三个list是有struct slab结构组成的链表。其中struct slab中的s_mem是第一个object的起始地址，因此就可以通过kmem_cache --> kmem_cache_node --> object找到空闲的object。其中slab中的page 的prev指向cache，next指向slab。

而slab还分为on-slab 和off-slab，是指当object的size特别大的时候，slab中新分配的page就全部放object，而struct slab结构单独从通用slab中进行分配，如果object的size比较小，则可以将struct slab放置在新分配的page开头，然后再放置object。

slab 分配器提供两个主要优点：

没有因碎片而引起内存浪费。碎片不是问题，因为每个内核数据结构都有关联的 cache，每个 cache 都由一个或多个 slab 组成，而 slab 按所表示对象的大小来分块。因此，当内核请求对象内存时，slab 分配器可以返回刚好表示对象的所需内存。

可以快速满足内存请求。因此，当对象频繁地被分配和释放时，如来自内核请求的情况，slab 分配方案在管理内存时特别有效。分配和释放内存的动作可能是一个耗时过程。然而，由于对象已预先创建，因此可以从 cache 中快速分配。再者，当内核用完对象并释放它时，它被标记为空闲并返回到 cache，从而立即可用于后续的内核请求。

通过命令sudo cat /proc/slabinfo可查看系统当前 slab 使用情况。slab 分配器的实现源码：

slub 分配器主要由 kmem_cache、kmem_cache_cpu、kmem_cache_node、slab 和 object 等关键数据结构组成，它们相互协作，共同完成内存的分配和管理工作 。我们来仔细看看，缓存区 struct kmem_cache 到底是什么样子。\include\linux\slab_def.h

在 struct kmem_cache 里面，有个变量 struct list_head list，这个结构很重要。我们可以想象一下，对于操作系统来讲，要创建和管理的缓存绝对不止 task_struct，还有 mm_struc，fs_struct 都需要。因此，所有的缓存最后都会放在一个链表里面，也就是 LIST_HEAD(slab_caches)。对于缓存来讲，其实就是分配了连续几页的大内存块，然后根据缓存对象的大小，切成小内存块。

接下来就是最重要的两个成员变量出场的时候了。kmem_cache_cpu 和 kmem_cache_node，它们都是每个 NUMA 节点上有一个，我们只需要看一个节点里面的情况。

在分配缓存块的时候，要分两种路径，fast path 和 slow path，也就是快速通道和普通通道。其中 kmem_cache_cpu 就是快速通道，kmem_cache_node 是普通通道。每次分配的时候，要先从 kmem_cache_cpu 进行分配。如果 kmem_cache_cpu 里面没有空闲的块，那就到 kmem_cache_node 中进行分配；如果还是没有空闲的块，才去伙伴系统分配新的页。

我们来看一下，kmem_cache_cpu 里面是如何存放缓存块的：

在这里，page 指向大内存块的第一个页，缓存块就是从里面分配的。freelist 指向大内存块里面第一个空闲的项。按照上面说的，这一项会有指针指向下一个空闲的项，最终所有空闲的项会形成一个链表。partial 指向的也是大内存块的第一个页，之所以名字叫 partial（部分），就是因为它里面部分被分配出去了，部分是空的。这是一个备用列表，当 page 满了，就会从这里找。

我们再来看 kmem_cache_node 的定义：

这里面也有一个 partial，是一个链表。这个链表里存放的是部分空闲的内存块。这是 kmem_cache_cpu 里面的 partial 的备用列表，如果那里没有，就到这里来找。

3.3slub 分配器的工作流程

slub 分配器的工作流程严谨而高效，主要包括内存分配和内存释放两个关键环节 ，下面我们就来看看这个分配过程。kmem_cache_alloc_node 会调用 slab_alloc_node。你还是先重点看这里面的注释，这里面说的就是快速通道和普通通道的概念：

快速通道很简单，取出 cpu_slab 也即 kmem_cache_cpu 的 freelist，这就是第一个空闲的项，可以直接返回了。如果没有空闲的了，则只好进入普通通道，调用 __slab_alloc。

在这里，我们首先再次尝试一下 kmem_cache_cpu 的 freelist。为什么呢？万一当前进程被中断，等回来的时候，别人已经释放了一些缓存，说不定又有空间了呢。如果找到了，就跳到 load_freelist，在这里将 freelist 指向下一个空闲项，返回就可以了。如果 freelist 还是没有，则跳到 new_slab 里面去。这里面我们先去 kmem_cache_cpu 的 partial 里面看。

如果 partial 不是空的，那就将 kmem_cache_cpu 的 page，也就是快速通道的那一大块内存，替换为 partial 里面的大块内存。然后 redo，重新试下。这次应该就可以成功了。如果真的还不行，那就要到 new_slab_objects 了。

在这里面，get_partial 会根据 node id，找到相应的 kmem_cache_node，然后调用 get_partial_node，开始在这个节点进行分配。

acquire_slab 会从 kmem_cache_node 的 partial 链表中拿下一大块内存来，并且将 freelist，也就是第一块空闲的缓存块，赋值给 t。并且当第一轮循环的时候，将 kmem_cache_cpu 的 page 指向取下来的这一大块内存，返回的 object 就是这块内存里面的第一个缓存块 t。如果 kmem_cache_cpu 也有一个 partial，就会进行第二轮，再次取下一大块内存来，这次调用 put_cpu_partial，放到 kmem_cache_cpu 的 partial 里面。

如果 kmem_cache_node 里面也没有空闲的内存，这就说明原来分配的页里面都放满了，就要回到 new_slab_objects 函数，里面 new_slab 函数会调用 allocate_slab。

在这里，我们看到了 alloc_slab_page 分配页面。分配的时候，要按 kmem_cache_order_objects 里面的 order 来。如果第一次分配不成功，说明内存已经很紧张了，那就换成 min 版本的 kmem_cache_order_objects。

3.4slub分配器的API使用

与 libc 提供的内存申请 API （malloc 和 free ）类似，Slab 分配器提供的 API 为 kmalloc()和 kfree()。kmalloc()函数定义在include/linux/slab.h文件中，接收两个参数，并调用__kmalloc()函数。最终分配内存的实现是__do_kmalloc()函数。

3.5数据结构

kmem_cache实例的成员cpu_slab指向array_cache实例，每个处理器对应一个array_cache实例，称为数组缓存，用来缓存刚刚释放的对象，分配时首先从当前处理器的数据缓存分配，避免每次都要从slab分配，减少链表操作的锁操作，提高分配的速度。

由于slab的缓存特性，slab 分配器从 buddy 分配器中获取的物理内存称为 内存缓存使用结构体struct kmem_cache（定义在include/linux/slab_def.h文件中）描述。 一个高速缓存中可以含有多个kmem_cache对应的高速缓存，就拿L1高速缓存来举例，一个L1高速缓存对应一个kmem_cache链表，这个链表中的任何一个kmem_cache类型的结构

体均描述一个高速缓存，而这些高速缓存在L1 cache中各自占用着不同的区域。

SLAB分配器由可变数量的缓存组成，这些缓存由称为“缓存链”的双向循环链表链接在一起（如下图中的 kmem_cache 链表）。 在slab分配器的上下文中，缓存是特定类型的多个对象的管理器，例如使用cat /proc/slabinfo命令输出的mm_struct 或fs_cache缓存，其名字保存在kmem_cache->name中（Linux 支持单个最大的 slab 缓存大小为32MB ）。kmem_cache 中所有对象的大小是相同的(object_size)，并且此 kmem_cache 中所有SLAB的大小也是相同的(gfporder、num)。

每个缓存节点在内存中维护称为slab的连续页块，这些页面被切成小块，用于缓存数据结构和对象。 kmem_cache的 kmem_cache_node 成员记录了该kmem_cache 下的所有 slabs 列表。形成的结构如下图所示。

以上3个链表保存的是slab 描述符，Linux kernel 使用 struct page 来描述一个slab。单个slab可以在slab链表之间移动，例如如果一个半满slab被分配了对象后变满了，就要从 slabs_partial 中被删除，同时插入到 slabs_full 中去。

page 结构体关于 slab 的部分。struct page定义在include/linux/mm_types.h文件中，与slab相关的结构体成员如下所示：

内存缓存为每个处理器创建一个数组缓存（结构体array_cache）。释放对象时，把对象存放到当前处理器对应的数组缓存中；分配对象的时候，先从当前处理器的数组缓存分配对象，采用后进先出（LIFO）原则，可以提高性能。

于所有对象空间的slab，没有立即释放，而是放在空闲slab链表中。只有内存节点上空闲对象的数量超过限制，才开始回收空闲slab，直到空闲对象的数量小于或等于限制。

四、三大分配器的协作与应用场景

在 Linux 内存管理这个庞大而复杂的系统中，引导内存分配器、伙伴分配器和 slab 分配器并非孤立存在，它们各司其职，又相互协作，共同为系统的稳定运行提供了强大的内存支持。在不同的内存需求场景下，这三大分配器展现出了各自的优势和特点，协同完成内存分配与管理的任务 。

在系统启动阶段，引导内存分配器率先登场，它就像是一场大型演出的开场嘉宾，为后续的精彩表演搭建起了舞台。在这个阶段，系统的内存管理机制还未完全建立，引导内存分配器承担起了为内核初始化提供内存的重任 。它通过简单而直接的方式，将物理内存划分为不同的区域，为内核的启动和基本数据结构的创建提供了必要的内存空间 。

例如，在 x86 架构的系统启动过程中，引导内存分配器会根据 BIOS 提供的内存信息，将内存划分为不同的块，标记出哪些区域是可用的，哪些是被系统保留的 。当内核开始初始化时，就可以从引导内存分配器分配的内存中获取所需的空间，用于创建进程控制块（PCB）、文件描述符表等重要的数据结构 。引导内存分配器的存在，为后续更复杂、更高效的内存分配器的初始化和运行奠定了基础 。

随着系统的启动完成，伙伴分配器和 slab 分配器开始发挥核心作用 。当系统中某个进程需要分配大量连续内存时，伙伴分配器就成为了最佳选择 。比如，在进行大数据处理时，需要一次性读取大量的数据到内存中进行分析计算 。假设要处理一个 1GB 大小的数据集，由于数据的连续性对于提高处理效率至关重要，此时就可以向伙伴分配器申请一块连续的 1GB 内存空间 。

伙伴分配器会根据其独特的算法，从物理内存中找到合适大小的连续页块进行分配 。它首先会查看是否有足够大的空闲页块直接满足请求，如果没有，就会从更大的页块中进行分裂，直到找到合适的内存块分配给进程 。这样，大数据处理程序就能够在分配到的连续内存空间中高效地进行数据读取和计算操作 。

而当系统中频繁出现对小对象的内存分配需求时，slab分配器就展现出了它的优势 。以网络通信为例，在网络数据包的处理过程中，会频繁地创建和销毁各种小的结构体，如套接字描述符、网络协议头部等 。这些小对象的大小通常小于一个页面大小（一般为 4KB） 。如果每次都使用伙伴分配器来分配内存，会因为其按照页块分配的特性，导致大量的内存浪费，并且分配和释放的效率也较低 。而 slab 分配器针对这种情况进行了优化，它预先为这些小对象创建了特定的缓存池 。

当需要分配一个套接字描述符时，slab 分配器可以直接从对应的缓存池中快速获取一个空闲的对象，无需进行复杂的内存搜索和分配操作 。当这个套接字描述符不再使用时，又可以迅速将其释放回缓存池，供下次使用 。这样，在高并发的网络通信场景下，slab 分配器能够大大提高内存分配和释放的速度，减少内存碎片的产生，保证网络通信的高效性和稳定性 。

在实际的 Linux 系统中，这三大分配器的协作是非常紧密的 。例如，slab 分配器在创建缓存池时，需要向伙伴分配器申请内存页块 。当 slab 分配器的某个缓存池需要扩充或收缩时，也会与伙伴分配器进行交互，获取或释放内存页块 。

而伙伴分配器在进行内存分配时，如果遇到内存不足的情况，可能会通过回收一些不常用的内存页来满足分配需求，这些被回收的内存页中可能就包含了 slab 分配器中一些空闲的对象 。通过这种相互协作的方式，三大分配器能够充分发挥各自的优势，满足系统中各种不同的内存需求，确保 Linux 系统在各种复杂的应用场景下都能高效、稳定地运行 。