探究slab在内核内存管理和用户态Memcached的双重存在

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

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

它的逻辑如下：

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

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

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

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

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

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

我们安装1个Memcached：

$ sudo apt-get install memcached

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

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

编辑：jq