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"!

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

image

为了改善多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.

阅读更多
个人分类: Unix 编程
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

不良信息举报

Solaris Slab Allocator –Magazines[1]

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭