kernel hacker修炼之道之内存管理-SLUB(SLUB的基本数据结构)

kernel hacker修炼之道之内存管理-SLUB

作者：李万鹏 于北京 borqs

2011.9.17 11:07

本SLUB系列文章从几个方面讨论：

1. SLUB的基本数据结构

2. 创建SLUB高速缓存kmem_cache_create()

3. 销毁SLUB高速缓存kmem_cache_destroy()

4. 创建SLAB块new_slab()

5. 撤销SLAB块free_slab()

6. 分配SLAB对象kmem_cache_alloc()

7. 释放SLAB对象kmem_cache_free()

8. SLUB系统的初始化代码

SLAB系列文档详细讲解了slab的框架源码，但是slab存在众多的不足。

1.复杂的队列管理机制。

2.数据结构过于庞大，浪费空间。

3.着色并不能完全解决cache miss。

4.对NUMA支持，内存回收，性能调优都非常复杂。

SLAB块的内部组织：

下边看一些核心数据结构：

struct kmem_cache {
	struct kmem_cache_cpu __percpu *cpu_slab;
	/* Used for retriving partial slabs etc */
	unsigned long flags;
	unsigned long min_partial;
	int size;		/* The size of an object including meta data */
	int objsize;		/* The size of an object without meta data */
	int offset;		/* Free pointer offset. */
	struct kmem_cache_order_objects oo;

	/* Allocation and freeing of slabs */
	struct kmem_cache_order_objects max;
	struct kmem_cache_order_objects min;
	gfp_t allocflags;	/* gfp flags to use on each alloc */
	int refcount;		/* Refcount for slab cache destroy */
	void (*ctor)(void *);
	int inuse;		/* Offset to metadata */
	int align;		/* Alignment */
	int reserved;		/* Reserved bytes at the end of slabs */
	const char *name;	/* Name (only for display!) */
	struct list_head list;	/* List of slab caches */
#ifdef CONFIG_SYSFS
	struct kobject kobj;	/* For sysfs */
#endif

#ifdef CONFIG_NUMA
	/*
	 * Defragmentation by allocating from a remote node.
	 */
	int remote_node_defrag_ratio;
#endif
	struct kmem_cache_node *node[MAX_NUMNODES];
};

每一个cache用一个struct kmem_cache进行描述。size是分配给对象的大小，objsize是对象的实际大小，offset是存放空闲对象指针的偏移。oo成员的高位保存页面的order，低位保存对象的个数。name是缓冲区的名字。struct kmem_cache_node为每个节点创建的slab信息的数据结构。

下边就是一个slab对象的结构：

struct kmem_cache_cpu {
	void **freelist;	/* Pointer to next available object */
#ifdef CONFIG_CMPXCHG_LOCAL
	unsigned long tid;	/* Globally unique transaction id */
#endif
	struct page *page;	/* The slab from which we are allocating */
	int node;		/* The node of the page (or -1 for debug) */
#ifdef CONFIG_SLUB_STATS
	unsigned stat[NR_SLUB_STAT_ITEMS];
#endif
};

struct kmem_cache_cpu就是percpu local slab了，freelist指向一个空闲对象队列的第一个对象。page指向slab的第一个物理页框，顺便说一下，在SLUB中没有slab描述符，而是用slab第一个物理页框的struct page结构，给page结构新增加几个字段，比如：

     union {
                atomic_t _mapcount;        /* Count of ptes mapped in mms,
                                         * to show when page is mapped
                                         * & limit reverse map searches.
                                         */
                struct {                /* SLUB */
                        u16 inuse;
                        u16 objects;
                };
        };

        union {
            struct {
                unsigned long private;
                struct address_space *mapping;
            };
            struct kmem_cache *slab;        /* SLUB: Pointer to slab */
            struct page *first_page;        /* Compound tail pages */
        };

        union {
                pgoff_t index;                /* Our offset within mapping. */
                void *freelist;                /* SLUB: freelist req. slab lock */
        };

他们都是union的，所以并不增加struct page结构的大小，也只有是slab第一个物理页框的页描述符的时候这些字段才有效。

struct kmem_cache_node {
	spinlock_t list_lock;	/* Protect partial list and nr_partial */
	unsigned long nr_partial;
	struct list_head partial;
#ifdef CONFIG_SLUB_DEBUG
	atomic_long_t nr_slabs;
	atomic_long_t total_objects;
	struct list_head full;
#endif
};

struct kmem_cache_node是与节点有关的，如果有多个节点就有多个kmem_cache_node，如文档上边的图，partial和full字段分别是slabs_partial和slabs_full这两个双向循环链表的头，nr_partial字段是slabs_partial链表上slab的数量。slabs_full链表也只是在调式的时候才打开，这里去掉了slabs_free链表，如果slab变成free了就直接释放掉，这样就不像SLAB那样需要复杂的回收算法了。

下边简单的对SLAB与SLUB进行一下比较：

1.SLUB只有slabs_full与slabs_partial两条链表

2.SLUB去掉了share local list

3.去掉了庞大的SLAB管理对象

4.去掉了着色，因为在SLAB 块比较多的时候着色就不怎么起作用了，反而SLUB中用的cache复用更能解决问题

5.local slab直接取到一个SLAB块而不是cpu local salb指针接管从share local list，再从slab list3，简化了slab管理