- 论坛徽章:
- 13
|
本帖最后由 _nosay 于 2016-10-10 14:38 编辑
slab的意思是“块”,如果程序中需要用到很多某个结构时,可以在初始化时向系统预先申请可以存放很多这种结构的一大块内存,并自己管理这块内存。比如解析网络协议时,不断有新的连接建立,老的连接断开,而每个连接需要用一个session结构管理,就可以预先向系统申请一块可以存10w个session的内存,之后就可以在这块内存上进行session结构的分配/释放,这样做主要有如下几点好处:
① 减小系统内存碎片化
分配/释放会造成内存的碎片化(比如分配了123,释放2,就会造成1~3这块内存不连续),这样session顶多导致这一块内存碎片化,而不是整个系统的内存。
② 最底层按页管理
页式内存管理时,内核按管理区、页对内存进行了划分,__alloc_pages(zonelist, order)是从zonelist指定的管理区分配2^order(order<=10)个页面。
页式内存管理相对于段式内存更先进,所以现代系统一般都使用页式内存管理,也就是说最底层管理内存的最小单元是页,即使需要分配的内存远小于一页,分配函数也会返回一页,这样就造成内存的浪费,所以就需要在最底层的基础上进行封装,以更小的单元进行管理,glibc的malloc/free以及slab正是对最底层的内存管理的进一步封装。
③ 路线缩短
特别是写应用程序时,如果按照slab的思路实现一个自己的内存管理模块,那么分配/释放时,直接在用户态就可以完成,而不需要通过malloc()库函数中的系统调用跑到内核态。
另外在自己的实现上,还可以通过调节分配对象的起始位置,提高高速缓存的命中。
④ 方便调试,因为所有管理结构都由自己设计,调试时可以通过这些信息看出很多问题。
回到协议解析的例子,如果程序跑的环境,同一时刻的会话量一般在8w左右,就可以程序启动时就分配10w个session所占的内存,再假设每个session结构200字节,再加上slab本身的管理信息,就是大约20MB内存。
如图,这20MB中除了存放10w个session的对象区外,还有一些管理信息:
① 用于记录这些sessions的使用情况。将10w个session的对象区看作一个数组,相应还设置了一个对象链接数组,用于将空闲的session“链”起来,slab_t的free成员则相当于“链表头”,指向第一个空闲session的下标。
② 网络的活跃程度,根据时段一直在变,比如白天有时候同一时刻会达到100w个session,夜晚只有10w个session,所以希望块数量可以增加/减少,在发现slab中没有空闲session结构时,再增加一个slab,发现持续一段时间使用量比总量少很多时,就可以“腾出”一个完全空闲的slab并释放。因此,在slab之上,还有一个管理结构,即kmem_cache_t结构,除了一个链表头以外,还有很多统计信息,以及下一个slab应该使用的着色区偏移(理解着色区作用,要先理解高速缓存原理:http://www.doc88.com/p-212945104357.html),构造/析构函数等。
内核好像还有个slub的内存管理,比如还有一个test结构也是200字节,那么分配session、test结构,实际上同样是需要一块200字节的内存,就可以从slub块分配,即slub的对象区不限于指定结构,只要大小相同即可,所以跟slab区别不大。
还有vmalloc()、kmalloc()这些,都是对最基础的内存管理的再次封装,glibc的malloc()又将内核中的内存管理接口封装了一遍。
|
|