宋宝华:slab在内核内存管理和用户态Memcached的双重存在

很多基础的概念,将跨越软件的层次而存在。比如slab,对于内核人员,我们都知道slab是buddy之上的一层。

image

因为buddy作为Linux内核最底层的内存管理器,它分配1页,2页,4页,2n页,但是作为内核的堆用户本身,经常只是调用kmalloc()申请一个小内存,或者调用kmem_cache_alloc()申请一个数据结构,2n页给它,会形成大量碎片浪费。所以slab找buddy要了2^n页后,内部切割为同样size的object,再给kmalloc和kmem_cache_alloc()拿走。

image

它的逻辑如下:

image

这样一种软件本质意义上的需求,不会因为只是内核就需要。比如同样的slab算法,也被著名的用户态软件Memcached需要着。

Memcached是一种分布式内存对象缓存系统,用于动态Web等应用以减轻数据库的负载。它在内存中缓存数据和对象,使用key-value对形式存储。它的网站首页 https://memcached.org/ 显示了它的基本用法逻辑:

image

Memcached的原理也类似内核态page cache的原理:

image

比如你查询一个数据库,可以先看看Memcached里面有没有命中,命中就直接从Memcached的内存里面拿到值了,没有的时候才需要去查数据库。查到后,可以把结果放入Memcached,这样下次再访问同样数据,不再需要进行数据库的查询动作。

Memcached也同样采用slab分配算法来组织数据的存放,里面可以组织不同大小的chunks:

image

正如Linux内核的每一种不同slab里面的object的大小不一样。

我们安装1个Memcached:

代码语言:javascript
复制
$ sudo apt-get install memcached

然后启动起来,你马上看到memcached打印说自己创建了各种不同chunk size的slab:

image

当然,还有更多的相似性,比如Memcached里面的对象,也是LRU算法替换。所以LRU这种,也是一种本质上的事情。