关闭

Solaris Slab Allocator –Magazines[1]

911人阅读 评论(0) 收藏 举报

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.

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:79967次
    • 积分:1455
    • 等级:
    • 排名:千里之外
    • 原创:60篇
    • 转载:0篇
    • 译文:8篇
    • 评论:16条
    最新评论