手动内存管理方法

1

 为了实现一个高并发的分布式web大数据查询引擎，需要避免在编程时频繁的执行malloc和free时所引起的巨大开销，我们调研了linux内核中的内存管理算法（Buddy系统和slab分配器）以及glibc malloc的实现中对于堆的管理。以下记为算法1和2.
 算法1 和 算法2 运行的的层面不一样，初步理解算法1管理的内存是RAM的部分内存。算法2管理的是用户的进程地址空间里的推段。（需要使用两个不同的内存管理算法的原因是不同层面的内存管理需求不一样）
 接下来将分别介绍对这两个算法的理解。

算法介绍

算法1

 linux将RAM提供的动态内存区域分为三个不同的内存管理区，每个内存管理区都有各自的Buddy系统和slab分配器。图一介绍了这三个内存管理区以及各自算法运行的位置[1]

Buddy系统

 Buddy系统可以为进程缺页时（内核态或者用户态）分配一组页框，当然，内核可以不通过缺页异常从Buddy系统申请内存（一组页框）。Buddy系统的一个优势就是避免了外部碎片，即不会出现大量的未使用的不连续的小页框（比如一个页框或者两个页框）。
 方法即是将内存分为不同大小的2的幂次的连续页框（1，2，4，8，16，32，64，128，256，512，1024）的集合（通过链表的形式组织）。分配的时候从最合适的页框集合中取，如果有，则返回。如果没有，则从上一级的页框中查找并且切分成两个当前页框大小的页框放入当前集合中，并分配一个给调用者即可。释放的时候逆向回收，即当有连续的同一大小的页框则合并并放到上一级的集合中，此过程是递归过程，直到最大的集合。

slab分配器

 从Buddy系统的介绍可以看出Buddy系统对处理小于一个页框的内存请求时，会分配一整个页框，会造成页内碎片。ULP中介绍slab分配器是运行在CPU高速缓存中算法，事实在slab分配器运行在内存管理分配器或者Buddy系统中都是可以的。将slab分配器运行在CPU高速缓存中有多个原因，其中一个是考虑到对伙伴系统函数的调用会弄脏高速缓存中的页框（高速缓存中保存着对Buddy系统申请的页框 ？？）。

 这里没有找到ULP第三版p325的图，用了IBM介绍slab的一张图。原理是一样的。
 slab分配器是一组slab的集合，包含一些特殊的结构体大小的内存对象（比如进程结构task_struct之类的）和一些一般大小的内存对象（按大小划分的，32bytes，64bytes，之类）。
 slab分配器是构建在cpu高速缓存上。

有空了继续总结。