Linux Slob分配器(一)--概述

水平有限，描述不当之处还请指出，转载请注明出处 http://blog.csdn.net/vanbreaker/article/details/7705202  

    Slob分配器相较Slab和Slub分配器而言，最大的特点就是简洁，其总共的实现代码大概就600多行，因此其适用于嵌入式系统。不同于Slab和Slub,Slob分配器没有引入本地CPU高速缓存和本地节点的概念。Slob分配器同样使用链表来管理slob，不过总共只存在三个全局partial_free链表，这三个链表是按对象大小来划分的。

[cpp] view plain copy print ?

1. #define SLOB_BREAK1 256   
2. #define SLOB_BREAK2 1024   
3. static LIST_HEAD(free_slob_small);  
4. static LIST_HEAD(free_slob_medium);  
5. static LIST_HEAD(free_slob_large);  

#define SLOB_BREAK1 256
#define SLOB_BREAK2 1024
static LIST_HEAD(free_slob_small);
static LIST_HEAD(free_slob_medium);
static LIST_HEAD(free_slob_large);

对于小于256字节的对象，将从free_slob_small链表中寻找slob进行分配

对于小于1024字节的对象，将从free_slob_medium链表中寻找slob进行分配

对于大于1024字节的对象，将从free_slob_large链表中寻找slob进行分配

对于大于PAGE_SIZE的对象，将直接通过伙伴系统分配，不经手Slob分配器

 

那么总共只有三个链表，Slob分配器的各类缓存怎么管理自己的空闲对象呢？实际上，所谓的不同类别的缓存都只是伪缓存，因为它们并没有专属自己的内存。当你在Slob分配器中创建一个缓存时，只是声明了该缓存的对象的大小size、对齐值align等，那么当要从该缓存分配对象时，将会根据size定位到相应的链表，寻求分配。因此专用缓存分配对象(kmem_cache_alloc())和普通缓存分配对象(kmalloc())并无太多区别，它们的对象都来源于这三个链表，只不过内核欺骗性的保留了这些接口而已。由此可以想象，struct kmem_cache这个结构在Slob分配器中是很简洁的

[cpp] view plain copy print ?

1. struct kmem_cache {  
2.     unsigned int size, align; //对象大小，对齐值   
3.     unsigned long flags;      //属性标识   
4.     const char *name;         //缓存名   
5.     void (*ctor)(void *);     //分配对象时的构造函数   
6. };  

struct kmem_cache {
	unsigned int size, align; //对象大小，对齐值
	unsigned long flags;      //属性标识
	const char *name;         //缓存名
	void (*ctor)(void *);     //分配对象时的构造函数
};

 

接下来的一个问题就是Slob分配器是如何描述slob的。在Slob分配器中，一个slob永远都是占用一个页框的大小，所以对于大于PAGE_SIZE的对象，会选择直接通过伙伴系统分配。Slob分配器将所有的slob组织在三个全局链表中，不过，这些slob的描述结构都不需要进行额外的分配。Slob分配器将描述slob的变量打包成一个结构，然后和页描述符struct page一起组成一个联合体，这样就可以直接利用页描述符已占有的空间，将页描述符中无关紧要的字段填充为slob的有效描述字段，这样便可以省下一笔内存了！

[cpp] view plain copy print ?

1. struct slob_page {  
2.     union {  
3.         struct {  
4.             unsigned long flags;/* 填充用，为了不覆盖page->flags */  
5.             atomic_t _count;      /* 填充用，为了不覆盖page->_count */  
6.             slobidx_t units;      /* slob的空闲单元数 */  
7.             unsigned long pad[2];  
8.             slob_t *free;       /* 指向第一个空闲块 */  
9.             struct list_head list;  /* 用于链入slob全局链表 */  
10.         };  
11.         struct page page;  
12.     };  
13. };  

struct slob_page {
	union {
		struct {
			unsigned long flags;/* 填充用，为了不覆盖page->flags */
			atomic_t _count;	  /* 填充用，为了不覆盖page->_count */
			slobidx_t units;	  /* slob的空闲单元数 */
			unsigned long pad[2];
			slob_t *free;		/* 指向第一个空闲块 */
			struct list_head list;	/* 用于链入slob全局链表 */
		};
		struct page page;
	};
};

我们可以看到，实际上真正用于slob管理的项只有三个，即units,free和list.

free和list的意义已经很清楚明了了，现在来解释下slobidx_t units这个玩意。unit是slob的粒度，也就是说当你分配内存时，必须分配出去N个unit，所有的管理都是基于unit的。unit的大小根据PAGE_SIZE的不同而不同，通常情况下为2个字节，关于unit大小的定义:

[cpp] view plain copy print ?

1. #if PAGE_SIZE <= (32767 * 2)   
2. typedef s16 slobidx_t;  
3. #else   
4. typedef s32 slobidx_t;  
5. #endif  

#if PAGE_SIZE <= (32767 * 2)
typedef s16 slobidx_t;
#else
typedef s32 slobidx_t;
#endif

既然slob的管理是基于unit的，那么units字段的含义也就很容易理解了，它表示的是slob中当前还剩余的空闲单元数目。

 

最后来讲讲最重要的一点，也就是slob是如何来组织空闲对象的。在slob中，更准确的说法不是对象而是块(block)，因为之前已经讨论过了，一个slob中可以有多种缓存来分配对象，因此可能出现多种大小不同的块！对于任何一个块来说，都必须拥有自己的管理数据，才能和其他的块进行联系。在Slob中，空闲块总是按地址顺序，链式连接的。

对于不同类型的块来说，其管理数据也略有不同:

• 对于空闲的普通块(占用的单元数大于1)，则第一个单元用来填充块的大小，第二个单元用来填充下一个空闲块的偏移
• 对于小得空闲块(只占用1个单元)，则该单元填充下一个空闲对象的偏移的相反数，也就是说是一个负数
• 对于已经分配出去的块，第一个单元用来填充块的大小

需要注意的是，第三点在分配普通缓存对象时才会存在，因为使用kfree时并不知道释放对象的大小，因此必须要在用kmalloc分配时就额外分配一个单元来记录块的大小，而分配专用缓存对象时，直接用sizeof()就可以知道释放对象的大小了! 为了便于访问前两个管理单元，Slob分配器声明了一个slob_block结构

[cpp] view plain copy print ?

1. struct slob_block {  
2.     slobidx_t units;  
3. };  

struct slob_block {
	slobidx_t units;
};

这样只要获取了一个块的地址s，再通过s[0],s[1]即可访问管理数据。

 

在slob刚被创建时，其只有一个块，而且该块的大小等于PAGE_SIZE，当第一次分配时就将其分裂成两个块，一个块为objsize，另一个剩余块为PAGE_SIZE - objsize(不考虑对齐等因素产生的碎片)，依次类推。Slob分配器采用的是first-fit算法，关于分配的具体过程，下节再做介绍。