宋宝华:slab在内核内存管理和用户态Memcached的双重存在
很多基础的概念,将跨越软件的层次而存在。比如slab,对于内核人员,我们都知道slab是buddy之上的一层。
因为buddy作为Linux内核最底层的内存管理器,它分配1页,2页,4页,2n页,但是作为内核的堆用户本身,经常只是调用kmalloc()申请一个小内存,或者调用kmem_cache_alloc()申请一个数据结构,2n页给它,会形成大量碎片浪费。所以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这种,也是一种本质上的事情。