1.原理说明
Linux内核中采 用了一种同时适用于32位和64位系统的内 存分页模型，对于32位系统来说，两级页表足够用了，而在x86_64系 统中，用到了四级页表，如图2-1所示。四级页表分别为：
* 页全局目录（Page Global Directory）
* 页上级目录（Page Upper Directory）
* 页中间目录（Page Middle Directory）
* 页表（Page Table）
页全局目录包含若干页上级目录的地址，页上级目录又依次包含若干页中间目录的地址，而页中间目录又包含若干页表的地址，每一个页表项指 向一个页框。Linux中采用4KB大小的 页框作为标准的内存分配单元。
多级分页目录结构
1.1.伙伴系统算法
在实际应用中，经常需要分配一组连续的页框，而频繁地申请和释放不同大小的连续页框，必然导致在已分配页框的内存块中分散了许多小块的 空闲页框。这样，即使这些页框是空闲的，其他需要分配连续页框的应用也很难得到满足。
为了避免出现这种情况，Linux内核中引入了伙伴系统算法（buddy system）。把所有的空闲页框分组为11个 块链表，每个块链表分别包含大小为1，2，4，8，16，32，64，128，256，512和1024个连续页框的页框块。最大可以申请1024个连 续页框，对应4MB大小的连续内存。每个页框块的第一个页框的物理地址是该块大小的整数倍。
假设要申请一个256个页框的块，先从256个页框的链表中查找空闲块，如果没有，就去512个 页框的链表中找，找到了则将页框块分为2个256个 页框的块，一个分配给应用，另外一个移到256个页框的链表中。如果512个页框的链表中仍没有空闲块，继续向1024个页 框的链表查找，如果仍然没有，则返回错误。
页框块在释放时，会主动将两个连续的页框块合并为一个较大的页框块。
1.2.slab分配器
slab分配器源于 Solaris 2.4 的 分配算法，工作于物理内存页框分配器之上，管理特定大小对象的缓存，进行快速而高效的内存分配。
slab分配器为每种使用的内核对象建立单独的缓冲区。Linux 内核已经采用了伙伴系统管理物理内存页框，因此 slab分配器直接工作于伙伴系 统之上。每种缓冲区由多个 slab 组成，每个 slab就是一组连续的物理内存页框，被划分成了固定数目的对象。根据对象大小的不同，缺省情况下一个 slab 最多可以由 1024个页框构成。出于对齐 等其它方面的要求，slab 中分配给对象的内存可能大于用户要求的对象实际大小，这会造成一定的 内存浪费。
2.常用内存分配函数
2.1.__get_free_pages
unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)
__get_free_pages函数是最原始的内存分配方式，直接从伙伴系统中获取原始页框，返回值为第一个页框的起始地址。__get_free_pages在实现上只是封装了alloc_pages函 数，从代码分析，alloc_pages函数会分配长度为1<<order的 连续页框块。order参数的最大值由include/linux/Mmzone.h文 件中的MAX_ORDER宏决定，在默认的2.6.18内 核版本中，该宏定义为10。也就是说在理论上__get_free_pages函 数一次最多能申请1<<10 * 4KB也就是4MB的 连续物理内存。但是在实际应用中，很可能因为不存在这么大量的连续空闲页框而导致分配失败。在测试中，order为10时分配成功，order为11则返回错误。
2.2.kmem_cache_alloc
struct kmem_cache *kmem_cache_create(const char *name, size_t size,
size_t align, unsigned long flags,
void (*ctor)(void*, struct kmem_cache *, unsigned long),
void (*dtor)(void*, struct kmem_cache *, unsigned long))
void *kmem_cache_alloc(struct kmem_cache *c, gfp_t flags)
kmem_cache_create/ kmem_cache_alloc是基于slab分配器的一种内存分配方式，适用于反复分配释放同一大小内存块的场合。首先用kmem_cache_create创建一个高速缓存区域，然后用kmem_cache_alloc从 该高速缓存区域中获取新的内存块。 kmem_cache_alloc一次能分配的最大内存由mm/slab.c文件中的MAX_OBJ_ORDER宏 定义，在默认的2.6.18内核版本中，该宏定义为5， 于是一次最多能申请1<<5 * 4KB也就是128KB的 连续物理内存。分析内核源码发现，kmem_cache_create函数的size参数大于128KB时会调用BUG()。测试结果验证了分析结果，用kmem_cache_create分 配超过128KB的内存时使内核崩溃。
