linuxslub分配器浅析.docVIP

【转】 linux slub分配器浅析 2011-07-18 09:45 转载自 分享 最终编辑 kouu 在《linux内存管理浅析》中提到内核管理自己使用的内存时，使用了SLAB对象池。SLAB确实是比较复杂，所以一直以来都没有深入看一看。 不过现在，linux内核中，SLAB已经被它的简化版--SLUB所代替。最近抽时间看了一下SLUB的代码，略记一些自己的理解。 尽管SLUB是在内核里面实现的，用户态的对象池其实也可以借鉴这样的做法。 SLUB的总体思想还是跟SLAB类似，对象池里面的内存都是以“大块”为单位来进行分配与回收的。然后每个“大块”又按对象的大小被分割成“小块”，使用者对于对象的分配与回收都是以“小块”为单位来进行的。 SLUB的结构如下图： 另外，kmem_cache还有以下一些参数（后面会解释到）： int size; /* 每个对象占用的空间 */ int objsize; /* 对象的大小 */ int offset; /* 对象所占用的空间中，存放next指针的偏移 */ int refcount; /* 引用计数 */ int inuse; /* 对象除next指针外所占用的大小 */ int align; /* 对齐字节数 */ void (*ctor)(void *); /* 构造函数 */ unsigned long min_partial; /* kmem_cache_node中保存的最小page数 */ struct kmem_cache_order_objects oo; /* 首选的page分配策略（分配多少个连续页面，能划分成多少个对象） */ struct kmem_cache_order_objects min; /* 次选的page分配策略 */ （另外还有一些成员，或支持了一些选项、或支持了DEBUG、或是为周期性的内存回收服务。这里就不列举了。） 大体结构 kmem_cache是对象池管理器，每一个kmem_cache管理一种类型的对象。所有的管理器通过双向链表由表头slab_caches串连起来。 这一点跟之前的SLAB是一样的。 kmem_cache的内存管理工作是通过成员kmem_cache_node来完成的。在NUMA环境下（非均质存储结构），一个kmem_cache维护了一组kmem_cache_node，分别对应每一个内存节点。kmem_cache_node只负责管理对应内存节点下的内存。（如果不是 NUMA环境，那么kmem_cache_node只有一个。） 而实际的内存还是靠page结构来管理的，kmem_cache_node通过partial指针串连起一组page（nr_partial代表链表长度），它们就代表了对象池里面的内存。page结构不仅代表了内存，结构里面还有一些union变量用来记录其对应内存的对象分配情况（仅当page被加入到SLUB分配器后有效，其他情况下这些变量有另外的解释）。 原先的SLAB则要复杂一些，SLAB里面的page仅仅是管理内存，不维护“对象”的概念。而是由额外的SLAB控制结构（slab）来管理对象，并通过slab结构的一些指针数组来划定对象的边界。 前面说过，对象池里面的内存是以“大块”为单位来进行分配与回收的，page就是这样的大块。page内部被划分成若干个小块，每一块用于容纳一个对象。这些对象是以链表的形式来存储的，freelist就是链表头，只有未被分配的对象才会放在链表中。对象的next指针存放在其偏移量为kmem_cache-offset的位置。（见上面的图） 而在SLAB中，“大块”则是提供控制信息的slab结构。page结构只表示内存，它仅是slab所引用的资源。 每一个page并不只代表一个页面，而是2^order个连续的页面，这里的order值是由kmem_cache里面的oo或min来确定的。分配页面时，首先尝试使用oo里面的order值，分配较合适大小的连续页面（这个值是在kmem_cache创建的时候计算出来的，使用这个值时需要分配一定的连续页面，以使得内存分割成“小块”后剩余的边角废料较少）。如果分配不成功（运行时间长了，内存碎片多了，分配大量连续页面就不容易了），则使用min里面的order值，分配满足对象大小的最少量的连续页面（这个值也是创建kmem_cache时计算出来的）。 kmem_cache_node通过partial指针串连的一组page，这些page必须是没被占满的（一个page被划分成objects个对象大小的空间，这些空间中有inuse个已经被使用。如果objects==inuse，则pa