系统架构设计原则 slub分配器

Linux的物理内存管理采用了以页为单位的buddy system（伙伴系统），但是很多情况下，内核仅仅需要一个较小的对象空间，而且这些小块的空间对于不同对象又是变化的、不可预测的，所以需要一种类似用户空间堆内存的管理机制(malloc/free)。然而内核对对象的管理又有一定的特殊性，有些对象的访问非常频繁，需要采用缓冲机制；对象的组织需要考虑硬件cache的影响；需要考虑多处理器以及NUMA架构的影响。90年代初期，在Solaris 2.4操作系统中，采用了一种称为“slab”（原意是大块的混凝土）的缓冲区分配和管理方法，在相当程度上满足了内核的特殊需求。

多年以来，SLAB成为linux kernel对象缓冲区管理的主流算法，甚至长时间没有人愿意去修改，因为它实在是非常复杂，而且在大多数情况下，它的工作完成的相当不错。但是，随着多处理器系统和 NUMA系统的广泛应用，SLAB 分配器逐渐暴露出自身的严重不足：

1). 缓存队列管理复杂；

2). 管理数据存储开销大；

3). 对NUMA支持复杂；

4). 调试调优困难；

5). 摒弃了效果不太明显的slab着色机制；

针对这些SLAB不足，内核开发人员Christoph Lameter在Linux内核2.6.22版本中引入一种新的解决方案：SLUB分配器。SLUB分配器特点是简化设计理念，同时保留SLAB分配器的基本思想：每个缓冲区由多个小的slab 组成，每个 slab 包含固定数目的对象。SLUB分配器简化kmem_cache，slab等相关的管理数据结构，摒弃了SLAB 分配器中众多的队列概念，并针对多处理器、NUMA系统进行优化，从而提高了性能和可扩展性并降低了内存的浪费。为了保证内核其它模块能够无缝迁移到SLUB分配器，SLUB还保留了原有SLAB分配器所有的接口API函数。

（注：本文源码分析基于linux-4.1.x）

整体数据结构关系如下图所示：

1 SLUB分配器的初始化

SLUB初始化有两个重要的工作：第一，创建用于申请struct kmem_cache和struct kmem_cache_node的kmem_cache；第二，创建用于常规kmalloc的kmem_cache。

1.1 申请kmem_cache的kmem_cache

第一个工作涉及到一个“先有鸡还是先有蛋”的问题，因为创建kmem_cache需要从kmem_cache的缓冲区申请，而这时候还没有创建kmem_cache的缓冲区。kernel的解决办法是先用两个静态变量boot_kmem_cache和boot_kmem_cache_node来保存struct kmem_cach和struct kmem_cache_node缓冲区管理数据，以两个静态变量为基础申请大小为struct kmem_cache和struct kmem_cache_node对象大小的slub缓冲区，随后再从这些缓冲区中分别申请两个kmem_cache，然后把boot_kmem_cache和boot_kmem_cache_node中的内容拷贝到新申请的对象中，从而完成了struct kmem_cache和struct kmem_cache_node管理结构的bootstrap（自引导）。

void __init kmem_cache_init(void)

{

//声明静态变量，存储临时kmem_cache管理结构

static __initdata struct kmem_cache boot_kmem_cache,

boot_kmem_cache_node;

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-76918-1.html