趣谈Linux操作系统学习笔记-内存管理（24讲）-小内存分配

前言：

重点讲解slub分配器原因:

内核里小内存分配一共有三种，SLAB/SLUB/SLOB，slub分配器是slab分配器的进化版，而slob是一种精简的小内存分配算法，主要用于嵌入式系统。慢慢的slab分配器或许会被slub取代，所以对slub的了解是十分有必要的。

slab分配器的弊端:

    slab分配器中每个node结点有三个链表，分别是空闲slab链表，部分空slab链表，已满slab链表，这三个链表中维护着对应的slab缓冲区。我们也知道slab缓冲区的内存是从伙伴系统中申请过来的，

    如果没有内存回收机制的情况下，只要申请的slab缓冲区就会存入这三个链表中，并不会返回到伙伴系统里，如果这个类型的SLAB迎来了一个分配高峰期，将会从伙伴系统中获取很多页面去生成许多slab缓冲区，之后这些slab缓冲区并不会自动返回到伙伴系统中，而是会添加到node结点的这三个slab链表中去，这样就会有很多slab缓冲区是很少用到的。

slub优势：

较大程度上避免了内存碎片问题,  slub分配器把node结点的这三个链表精简为了一个链表，只保留了部分空slab链表，而SLUB中对于每个CPU来说已经不使用空闲对象链表，而是直接使用单个slab，并且每个CPU都维护有自己的一个部分空链表。

在slub分配器中，对于每个node结点，也没有了所有CPU共享的空闲对象链表。我们用以下图来表示以下slab分配器和slub分配器的区别(上图为SLAB，下图为SLUB)：

区别：

1.单个SLAB分配器结构

 2.单个SLUB分配器结构

slub 分配器讲解：

创建进程的时候涉及两个操作：

kmem_cache_alloc_node：每次创建 task_struct 的时候，我们不用到内存里面去分配，先在缓存里面看看有没有直接可用的，在 task_struct 的缓存区域 task_struct_cachep 分配了一块内存

task_struct_cachep定义：static struct kmem_cache *task_struct_cachep;

kmem_cache_free： 当一个进程结束，task_struct 也不用直接被销毁，而是放回到缓存中，这样，新进程创建的时候，我们就可以直接用现成的缓存中的 task_struct 了

SLUB分配器的描述符，struct kmem_cache结构：

             1
            struct
             kmem_cache {

             2
            struct kmem_cache_cpu __percpu *cpu_slab;
 3/* 标志 */ 4     unsigned long flags;
 5/* 每个node结点中部分空slab缓冲区数量不能低于这个值 */ 6     unsigned long min_partial;
 7/* 分配给对象的内存大小(大于对象的实际大小，大小包括对象后边的下个空闲对象指针) */ 8int size;    
 9/* 对象的实际大小 */10int object_size;  
11/* 存放空闲对象指针的偏移量 */12int offset;  
13/* cpu的可用objects数量范围最大值 */14int cpu_partial;   
15/* 保存slab缓冲区需要的页框数量的order值和objects数量的值，通过这个值可以计算出需要多少页框，这个是默认值，初始化时会根据经验计算这个值 */16struct kmem_cache_order_objects oo;
1718/* 保存slab缓冲区需要的页框数量的order值和objects数量的值，这个是最大值 */19struct kmem_cache_order_objects max;
20/* 保存slab缓冲区需要的页框数量的order值和objects数量的值，这个是最小值，当默认值oo分配失败时，会尝试用最小值去分配连续页框 */21struct kmem_cache_order_objects min;
22/* 每一次分配时所使用的标志 */23    gfp_t allocflags;   
24/* 重用计数器，当用户请求创建新的SLUB种类时，SLUB 分配器重用已创建的相似大小的SLUB，从而减少SLUB种类的个数。 */25int refcount;  
26/* 创建slab时的构造函数 */27void (*ctor)(void *);
28/* 元数据的偏移量 */29int inuse;   
30/* 对齐 */31int align;      
32int reserved;      
33/* 高速缓存名字 */34constchar *name;    
35/* 所有的 kmem_cache 结构都会链入这个链表，链表头是 slab_caches */36struct list_head list;    
37#ifdef CONFIG_SYSFS
38/* 用于sysfs文件系统，在/sys中会有个slub的专用目录 */39struct kobject kobj;   
40#endif41#ifdef CONFIG_MEMCG_KMEM
42/* 这两个主要用于memory cgroup的，先不管 */43struct memcg_cache_params *memcg_params;
44int max_attr_size; 
45#ifdef CONFIG_SYSFS
46struct kset *memcg_kset;
47#endif48#endif4950#ifdef CONFIG_NUMA
51/* 用于NUMA架构，该值越小，越倾向于在本结点分配对象 */52int remote_node_defrag_ratio;
53#endif54/* 此高速缓存的SLAB链表，每个NUMA结点有一个，有可能该高速缓存有些SLAB处于其他结点上 */55struct kmem_cache_node *node[MAX_NUMNODES];
56 };

kmem_cache结构，最重要的有4个：

　　每CPU对应的cpu_slab结构，

　　每个node结点对应的kmem_cache_node结构，

　　slub重用以及struct kmem_cache_order_objects结构对应的oo,

　　max,min这三个值

除去以上4个，简单说说kmem_cache中的一些成员变量：

• size：size = 对象大小 + 对象后面紧跟的下个空闲对象指针。
• object_size：对象大小。
• offset：对象首地址 + offset = 下个空闲对象指针地址
• min_partial：node结点中部分空slab缓冲区数量不能小于这个值，如果小于这个值，空闲slab缓冲区则不能够进行释放，而是将空闲slab加入到node结点的部分空slab链表中。
• cpu_partial：同min_partial类似，只是这个值表示的是空闲对象数量，而不是部分空slab数量，即CPU的空闲对象数量不能小于这个值，小于的情况下要去对应node结点的部分空链表中获取若干个部分空slab。
• name：该kmem_cache的名字

将大内存块切分成小内存块，模型如下图：

 每一项的结构都是缓存对象后面跟一个下一个空闲对象的指针，这样非常方便将所有的空闲对象链成一个链

kmem_cache_cpu  kmem_cache_node：

作用：那这些缓存对象哪些被分配了、哪些在空着，什么情况下整个大内存块都被分配完了，需要向伙伴系统申请几个页形成新的大内存块，对这些信息维护

关系图：

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

kmem_cache_cpu结构：

             1
            struct
             kmem_cache_cpu {

             2
            /*
             指向下一个空闲对象，用于快速找到对象 
            */
             3
            void **freelist;
 4/* 用于保证cmpxchg_double计算发生在正确的CPU上，并且可作为一个锁保证不会同时申请这个kmem_cache_cpu的对象 */ 5     unsigned long tid;    
 6/* CPU当前所使用的slab缓冲区描述符，freelist会指向此slab的下一个空闲对象 */ 7struct page *page;    
 8/* CPU的部分空slab链表，放到CPU的部分空slab链表中的slab会被冻结，而放入node中的部分空slab链表则解冻，冻结标志在slab缓冲区描述符中 */ 9struct page *partial;
10#ifdef CONFIG_SLUB_STATS
11    unsigned stat[NR_SLUB_STAT_ITEMS];
12#endif13 };

在此结构中主要注意有个partial部分空slab链表以及page指针：

age指针：指向当前使用的slab缓冲区描述符，内核中slab缓冲区描述符与页描述符共用一个struct page结构。SLUB分配器与SLAB分配器有一部分不同就在此，SLAB分配器的每CPU结构中保存的是空闲对象链表，而SLUB分配器的每CPU结构中保存的是一个slab缓冲区

tid，它主要用于检查是否有并发，对于一些操作，操作前读取其值，操作结束后再检查其值是否与之前读取的一致，非一致则要进行一些相应的处理，这个tid一般是递增状态，每分配一次对象加1

这个结构说明了一个问题，就是每个CPU有自己当前使用的slab缓冲区，CPU0不能够使用CPU1所在使用的slab缓存，CPU1也不能够使用CPU0正在使用的slab缓存。而CPU从node获取slab缓冲区时，一般倾向于从该CPU所在的node结点上分配，如果该node结点没有空闲的内存，则根据memcg以及node结点的zonelist从其他node获取slab缓冲区。这些具体可以在代码中见到

kmem_cache_node结构：

             1
            struct
             kmem_cache_node {

             2
            /*
             锁 
            */
             3
                spinlock_t list_lock;

             4
             5
            /*
             SLAB使用 
            */
             6
            #ifdef CONFIG_SLAB

             7
            /*
             只使用了部分对象的SLAB描述符的双向循环链表 
            */
             8
            struct list_head slabs_partial;    /* partial list first, better asm code */ 9/* 不包含空闲对象的SLAB描述符的双向循环链表 */10struct list_head slabs_full;
11/* 只包含空闲对象的SLAB描述符的双向循环链表 */12struct list_head slabs_free;
13/* 高速缓存中空闲对象个数(包括slabs_partial链表中和slabs_free链表中所有的空闲对象) */14     unsigned long free_objects;
15/* 高速缓存中空闲对象的上限 */16     unsigned int free_limit;
17/* 下一个被分配的SLAB使用的颜色 */18     unsigned int colour_next;    /* Per-node cache coloring */19/* 指向这个结点上所有CPU共享的一个本地高速缓存 */20struct array_cache *shared;    /* shared per node */21struct alien_cache **alien;    /* on other nodes */22/* 两次缓存收缩时的间隔，降低次数，提高性能 */23     unsigned long next_reap;    
24/* 0:收缩  1:获取一个对象 */25int free_touched;        /* updated without locking */26#endif2728/* SLUB使用 */29#ifdef CONFIG_SLUB
30     unsigned long nr_partial;
31struct list_head partial;
32#ifdef CONFIG_SLUB_DEBUG
33/* 该node中此kmem_cache的所有slab的数量 */34    atomic_long_t nr_slabs;
35/* 该node中此kmem_cache中所有对象的数量 */36    atomic_long_t total_objects;
37struct list_head full;
38#endif39#endif4041 };

这个结构中我们只需要看#ifdef CONFIG_SLUB部分，这个结构里正常情况下只有一个node结点部分空slab链表partial，如果在编译内核时选择了CONFIG_SLUB_DEBUG选项，则会有个node结点满slab链表。对于SLAB分配器，SLUB分配器在这个结构也做出了相应的变化，去除了满slab缓冲区链表和空闲slab缓冲区链表，只使用了一个部分空slab缓冲区链表。对于所有的CPU来说，它们可以使用这个node结点里面部分空链表中保存的那些slab缓冲区，当它们需要使用时，要先将缓冲区拿到CPU对应自己的链表或者当前使用中，也就是说node结点上部分空slab缓冲区同一个时间只能让一个CPU使用。

　　而关于slub重用，这里只做一个简单的解释，其作用是为了减少slub的种类，比如我有个kmalloc-8类型的slub，里面每个对象大小是8，而我某个驱动想申请自己所属的slub，其对象大小是6，这时候系统会给驱动一个假象，让驱动申请了自己专属的slub，但系统实际把kmalloc-8这个类型的slub返回给了驱动，之后驱动中分配对象时实际上就是从kmalloc-8中分配对象，这就是slub重用，将相近大小的slub共用一个slub类型，虽然会造成一些内碎片，但是大大减少了slub种类过多以及减少使用了跟多的内存。

　　最后说说struct kmem_cache_order_objects结构对应的oo,max,min这三个值，struct kmem_cache_order_objects结构实际上就是一个unsigned long，这个结构有两个作用，保存一个slab缓冲区占用页框的order值和一个slab缓冲区对象数量的值。当kmem_cache需要创建一个新的slab缓冲区时，会使用它们当中保存的oder值去申请2的order次方个数的页框。oo是一个默认值，在大多数情况下创建一个新的slab缓冲区时会用oo中的值来申请页框，而min是在oo申请失败的情况下使用，它是一个比oo更小的值，当伙伴系统拿不出oo中指定的数量的页框，会尝试向伙伴系统申请min中指定的页框数量(这个slab缓冲区连续页框数量少，对象数量也会少)。而max的值是在做slab缓冲区压缩时使用，其作用更多的是作为一个安全值，在这个kmem_cache中所有slab缓冲区的objects数量都不会大于max中的值。所有情况都是max >= oo > min。

SLUB分配器是如何运作

kmem_cache初始化后其是没有slab缓冲区的，当其他模块需要从此kmem_cache中申请一个对象时，kmem_cache会从伙伴系统获取连续的页框作为一个slab缓冲区，然后通过kmem_cache中的cotr函数指针指向的构造函数构造初始化这个slab缓冲区后，将其设置为该cpu的当前使用slab缓冲区，当此slab缓冲区使用完后，外部模块在申请对象时，会把这个满的slab缓冲区移除，再从伙伴系统获取一段连续页框作为一个新的空闲slab缓冲区，也是设置为该CPU当前使用的slab缓冲区。而那些满slab缓冲区中有对象释放时，SLUB分配器优先把这些缓冲区放入该CPU对应的部分空slab链表。而当一个部分空slab通过释放对象成为了一个空闲slab缓冲区时，SLUB分配器会视情况而定将此空闲slab释放还是加入到node结点的部分空slab链表中。

　　我们先看看一个slub初始化结束的情况：

　　初始化完成后，slub中并没有一个slab缓冲区，只有在第一次申请时，才会从伙伴系统中获取一段连续页框作为一个slab缓冲区，如下：

　　这时候当前CPU获得了一个空闲slab缓冲区，并将其中的一个空闲对象分配出去，而下次申请对象时也会从该slab缓冲区中获取对象，直到此缓冲区中对象用完为止。

　　上面描述的是初始化完成后第一次申请对象的情况，现在我们描述一下运行时申请对象的情况，一种情况是当前CPU使用的slab缓冲区有多余的空闲对象，这样直接从这些多余的空闲对象中分配一个出去即可，这种情况很简单。我们着重说明CPU使用的slab缓冲区没有多余的空闲对象的情况，这种情况又分为CPU的部分空slab链表是否为空的情况，如果CPU部分空slab链表不为空，则CPU会将当前使用的满slab移除，并从CPU的部分空slab链表中获取一个部分空的slab缓冲区，并设置为CPU当前使用的slab缓冲区，如下图：

　　如果node的部分空链表和CPU的部分空链表都为空的情况，那就与我们第一次申请对象的情况一样，直接从伙伴系统中获取连续页框用于一个slab缓冲区。

　　现在我们再说说CPU当前使用的slab已满，CPU的部分空slab链表为空的情况，这种情况下，会从node结点的部分空slab链表获取若干个部分空slab缓冲区，将它们放入CPU的部分空slab链表中，获取的slab缓冲区个数根据一个规则就是：cpu空闲的对象数量必须要大于kmem_cache中的cpu_partial的值的一半。具体如下：

 　　各种情况的申请对象都已经说明了，接下来我们说说释放对象的情况，释放对象也分很多种，我们先说说最简单的一种释放情况，就是部分空的slab释放其中一个使用着的对象，释放后这个部分空slab还是部分空slab(有些部分空slab只使用了一个对象，释放这个对象后就变为空闲slab)，这些部分空slab可能处于CPU当前使用slab，CPU部分空链表，node部分空链表中，但是它们的处理都是一样的，直接释放掉该对象即可，如下：

　　另一种情况是满slab缓冲区释放对象后变为了部分空slab缓冲区，这种情况下系统会将此部分空slab缓冲区放入CPU的部分空链表中，如下：

　　最后一种释放情况就是部分空slab释放一个对象后转变成了空闲slab缓冲区，而对于这个空闲slab缓冲区的处理，系统首先会检查node部分空链表中slab缓冲区的个数，如果node部分空链表中slab缓冲区数量小于kmem_cache中的min_partial，则将这个空闲slab缓冲区放入node部分空链表中。否则释放此空闲slab，将其占用页框返回伙伴系统中。我们知道部分空slab有可能存在于3个地方，CPU当前使用的slab缓冲区，CPU部分空链表，node部分空链表，这三个地方对于这种情况下的处理都是一样的，如下：

 　　这样看来只有空闲的slab缓冲区会被放入node结点的部分空链表中，这只是从释放对象的角度看是这样的，当刷新kmem_cache时，会将kmem_cache中所有的slab缓冲区放回到node结点的部分空链表(也包括当前CPU使用的slab缓冲区)，这种情况node结点的部分空链表就会有部分空slab缓冲区了。而还有一种情况就是编译时禁用了CPU的部分空链表，即CPU只有一个当前使用的slab缓冲区，这样其他的部分空缓冲区都会保存在node结点的部分空链表上，更多详细细节请看内核源码中的mm/slub.c文件

页面换出

什么情况下会触发页面换出

1. 最常见的情况就是，分配内存的时候，发现没有地方了，就试图回收一下。例如，咱们解析申请一个页面的时候，会调用 get_page_from_freelist，接下来的调用链为 get_page_from_freelist->node_reclaim->__node_reclaim->shrink_node，通过这个调用链可以看出，页面换出也是以内存节点为单位的

2. 作为内存管理系统应该主动去做的，而不能等真的出了事儿再做，这就是内核线程 kswapd。这个内核线程，在系统初始化的时候就被创建。这样它会进入一个无限循环，直到系统停止。在这个循环中，如果内存使用没有那么紧张，那它就可以放心睡大觉；如果内存紧张了，就需要去检查一下内存，看看是否需要换出一些内存页

总结

对于物理内存来讲，从下层到上层的关系及分配模式如下：

物理内存分 NUMA 节点，分别进行管理；

每个 NUMA 节点分成多个内存区域；

每个内存区域分成多个物理页面；

伙伴系统将多个连续的页面作为一个大的内存块分配给上层；

kswapd 负责物理页面的换入换出；

Slub Allocator 将从伙伴系统申请的大内存块切成小块，分配给其他系统

原文：https://www.cnblogs.com/mysky007/p/12316168.html