Linux内存管理之slab分配器分析(一)

一：准备知识：

前面我们分析过了大内存分配的实现机制，事实上,若为小块内存而请求整个页面，这样对于内存来说是一种极度的浪费。因此linux采用了slab来管理小块内存的分配与释放。Slab最早是由sun的工程师提出。它的提出是基于以下因素考虑的：

1：内核函数经常倾向于反复请求相同的数据类型。比如：创建进程时，会请求一块内存来存放mm结构。

2：不同的结构使用不同的分配方法可以提高效率。同样，如果进程在撤消的时候，内核不把mm结构释放掉，而是存放到一个缓冲区里，以后若有请求mm存储空间的行为就可以直接从缓冲区中取得，而不需重新分配内存.

3:前面我们曾分析过，如果伙伴系统频繁分配，释放内存会影响系统的效率，以此，可以把要释放到的内存放到缓冲区中，直至超过一个阀值才把它释放至伙伴系统，这样可以在一定程度上缓减减伙伴系统的压力

4:为了缓减“内碎片”的产生，通常可以把小内存块按照2的倍数组织在一起，这一点和伙伴系统类似

二：slab分配器概貌：

Slab将缓存分为两种：一种是专用高速缓存，另外一种是普通高速缓存。请注意，这里所说的高速缓存和硬件没有必然的关系，它只是slab分配器中的一个软件概念。

专用高速缓存中用来存放内核使用的数据结构，例如：mm,skb,vm等等

普通高速缓存是指存放一般的数据，比如内核为指针分配一段内存

所有的高速缓存区都通过链表的方式组织在一起，它的首结点是cache_chain

另外，普通高速缓存将分配区分为32*(2^0),32*(2^1),32*(2^2) ….32*(2^12)大小，共13个区域大小，另外，每个大小均有两个高速缓存，一个为DMA高速缓存，一个是常规高速缓存。它们都存放在一个名这cache_size的表中.

Slab分配器把每一个请求的内存称之为对象（和oop设计方法中的对象类似，都有初始化与析构）.对象又存放在slab中.slab又按照空，末满，全满全部链接至高速缓存中.如下图所示：

 

 

三：slab分配器相关的数据结构：

缓冲区

 

   slab

 

 

 

  slab

 

 

 

 

 

对象

 

高速缓存：

typedef struct kmem_cache_s kmem_cache_t;

struct kmem_cache_s {

struct array_cache *array[NR_CPUS];/*per cpu结构，每次分配与释放的时候都先从这里取值与存值*/

unsigned int       batchcount;  /*array[NR_CPUS]中没有空闲对象时，一次为数组所分配的对象数*/

unsigned int       limit;   /* array[NR_CPUS]中所允许的最大空闲数 */

struct kmem_list3  lists;   /*将在后面分析*/

unsigned int       objsize; /*slab中的对象大小*/

     unsigned int      flags;   /* cache标志*/

     unsigned int       num; /*每个slab中的对象数量 */

     unsigned int       free_limit; /* upper limit of objects in the lists */

     spinlock_t         spinlock;

     unsigned int       gfporder; /*2^gfporder即为cache中slab的大小*/

     unsigned int       gfpflags;

 

     size_t             colour;       /*着色机制，后面会详细分析 */

     unsigned int       colour_off;   /* colour offset */

     unsigned int       colour_next;  /* cache colouring */

     kmem_cache_t       *slabp_cache;/*slab描述符放在缓存区外面时，此值指向描述符在普通缓存区中的位置*/

     unsigned int       slab_size;  /*每一个slab的大小*/

     unsigned int       dflags;       /* dynamic flags */

     void (*ctor)(void *, kmem_cache_t *, unsigned long); /*构造函数*/

     void (*dtor)(void *, kmem_cache_t *, unsigned long); /*析构函数*/

     const char         *name; /*cache的名字*/

     struct list_head   next; /*下一个cache 用来构成链表*/

 

/* 5) statistics */

#if STATS

     unsigned long      num_active;

     unsigned long      num_allocations;

     unsigned long      high_mark;

     unsigned long      grown;

     unsigned long      reaped;

     unsigned long          errors;

     unsigned long      max_freeable;

     atomic_t      allochit;

     atomic_t      allocmiss;

     atomic_t      freehit;

     atomic_t      freemiss;

#endif

#if DEBUG

     int           dbghead;

     int           reallen;

#endif

}

这里值得注意的地方是，与2.4相比，slab部份的结构与成员位置发生了很大改变。一般来说经常用的成员放在结构体的前面。后面会解述为什么。

 

在cache这个结构里，有两个很重要的结构：struct array_cache   *array[NR_CPUS]与struct kmem_list3   lists;详细分析一下

struct array_cache {

     unsigned int avail;    //当前空闲对象的位置 

     unsigned int limit;    //允许的空闲对象的最大值

     unsigned int batchcount;    //一次要填充给数组的对象数，或者一次要释放的对象数

     unsigned int touched;       //如果从该组中分配了对象，则把此值置为1

}

struct kmem_list3 {

     struct list_head   slabs_partial;     /*末满的slab链 */

     struct list_head   slabs_full;   /*满的slab链*/

     struct list_head   slabs_free;   /*完全空闲的slab链*/

     unsigned long free_objects;      /*空链的对象数*/

     int      free_touched;

     unsigned long next_reap;

     struct array_cache *shared;      /*全局shar数组。当array[NR_CPUS]满了之后，会将对象释放至此，array[NR_CPUS]请求对象时，会先在这里取得对象 */

}

Slab的数据结构

struct slab {

     struct list_head   list;         /*用来构成链表*/

     unsigned long      colouroff;    /*着色机制，后面会详解*/

     void          *s_mem;       /* 首个对象的起始地址 */

     unsigned int       inuse;        /* slab中的使用对象个数 */

     kmem_bufctl_t      free;         /*slab中的第一个空闲对象的序号*/

};

四：slab中的着色机制

在我们分析详细的代码之前，有必要首先了解一下slab的着色机制。

Slab中引用着色机制是为了提高L1缓冲的效率。我们知道linux是一个兼容性很高的平台，但现在处理器的缓冲区方式多种多样，有的每个处理器有自己的独立缓存。有的很多处理器共享一个缓存。有的除了一级缓存（L1）外还是二级缓存（L2），因此，linux为了更好的兼容处理平台，只优化了一级缓存

为了下面的分析，我们不妨假设一下：假设处理器每根缓存线为32字节，L1大小为16K （可以算出共有512根缓存线）,每根缓存线与主存交互的大小也被称为cache line ，在这个例子中cache line是32字节

只有当处理器检测到缓存线冲突时（读或者写失效），才会与主存交互，例如当处理器检测到缓存读失效，会将相应地址所在的32字节读取到缓存。有这里有一点要注意的是，缓存与主存的交互是按照块大小来的，即一次读或者写32字节。而且每条缓存线所读取的地址不是任意的。例如：第0根缓存总线只能读取 0~32 16K ~ 16K+32  32K~32K+32的地址

Slab分配器要求对象按照cache line对齐，我们来看一下，如果没有对齐，会造成什么样的影响：

假设对象为20个字节，一个对象的起始地址是0 位于第0条缓存线。第二个地址的0~9位于第0条缓存线，10~19位于第1条缓存线。可以想象一下，如果要读入第二个对象，就会刷新二个缓存，共64个字节的数据。若是按照cache line对齐，则只要刷新一次高速缓存，只要交互32字节的数据。

当然，如果对象大小太小，我们是以cache line折半来对齐的，这我们在后面的代码中可以看到

讨论完cache line对齐之后，我们再来看看什么叫着色。

假设现在有这样的两个对象A，B A位于0~64于，第0条缓存线。B位于16K之后的64个字节，也是第0条缓存线。我们在上面的分析可以看到，常用的数据结构经常放在结构体的前面。此时就会有高32位的访问频率大大高于低32位的访问频率。假设此时，访问A之后再来访问B。高位访问50次，低位访问10次。

我们来看看这时的情况：

处理器在访问完A后，再访问B的地址，发现B需要缓冲线0，则把缓冲线0的数据写回主存，再读入B的值，访问完B后，发现又要访问A，此时，又把B的值写回主存，再读入A的值 …

按这样计算，共需要和主存交互50*2 + 10*2 = 120次

我们不妨把B后移32字节，这样B的高32位就位于缓存线1 低32位处于缓存线2。这时，访问完A后，访问B只需要把B的数据读科第1，第2缓存线，直接交互就行了。

如果经常有这样的情况发生，就会产生极大的“颠簸”，极度影响系统效率

基于这样的情况。Slab 分器配把每一个slab都错开了，都往后移了一个或者是多个cache line

详细情况可以参考：

)

在此非常感谢linuxforum的lucian_yao,你的文章给了我极大的帮助 ^_^