Solaris Slab Allocator –Magazines[1]

Overview

经典的slab allocator算法在多CPU系统中scalability不是很好，因为它的slab list是一个全局结构，分配和释放的时候需要一个global lock来保护list数据，这样等于线性化了所有分配操作。为了弥补这个不足，Solaris提出了per-CPU cache的策略。基本思想就是为每个CPU维护一个可以容纳M个Object的Cache, 学名叫作Magazine, Magazine除了杂志的意思外，还有一个意思是‘弹药库’。资源分配时先向这个Magazine Layer申请，如果Magazine Layer空了，Magazine Layer会自动"装填弹药reload"!

下面这张图展示了整个流程：

为了改善多CPU下的性能，我们在Slab Layer之上，添加了Magazine Layer, Magazine Layer有两层，CPU Layer和Depot Layer。注意到cache_cpu是每个CPU一个的，如果当前的cache_cpu能够满足资源分配需求，就不需要involve全局锁。

以cache_cpu[0]来说，其实它维护了两个Magazine：loaded和Previous，图中的每个magazine都可容纳8个大小相同的objects。这里的实现是每个 magazine都是一个拥有M个指针的array。其行为类似于stack:

分配： obj = magazine[--rounds];
释放:   magazine[rounds++] = obj;

我这里给出magazine的定义：[感谢open solaris,使得源代码公开]

typedef struct umem_magazine {
     void    *mag_next;
     void    *mag_round[1];         /* one or more rounds */
} umem_magazine_t;

这里解释一下solaris为什么使用数组mag_round[1]来维护objects而不是使用list? 

1. slab allocator的中心思想之一就是希望分配时直接拿到"准备好的constructed" object。使用listing会强迫被link的object的数据结构中含有object*的指针。于是每次分配和释放就会要修改处在object内部的指针。这样就破坏了constructed的原始状态，给分配和释放造成额外负担。
2. slab allocator的设计初衷是可以用来管理"任何"资源。而被管理的资源object并不一定都是writable memory。

下一篇我会介绍solaris的magazine如何克服"抖动thrashing"问题，使得cache的missing rate不高于1/M。

有兴趣的同学可以参考英语原文：

Magazines and Vmem:
Extending the Slab Allocator to Many CPUs and Arbitrary Resources.