宋宝华：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这种，也是一种本质上的事情。
