深刻理解Linux内存分配

深刻理解Linux内存分配

为了写一个用户层程序，你也许会声明一个全局变量，这个全局变量多是一个int类型也多是一个数组，而声明以后你有可能会先初始化它，也有可能放在以后用到它的时候再初始化。除此以外，你有可能会选择在函数内部去声明局部变量，又或者为变量动态申请内存。

无论你在用户程序中采起哪一种方式申请内存，这些都对应着不一样的内存分配方式以及不一样的数据段，若是再加上代码段，就构成了一个完整的进程。因而可知，一个完整的进程在内存空间中对应着不一样的数据区，具体来讲，对应着五种不一样的数据区：

代码段,存放操做指令；数据段,存放已初始化的全局变量；BSS段,存放未初始化的全局变量；堆,存放动态分配的内存(e.g.,malloc())；栈,存放临时建立的局部变量。

当你习惯写用户程序时，你不会去太多考虑你声明的变量最后都放到内存哪里去了，若是你仍然以为这不是你应该了解的事情，后面的内容你就能够不用浪费时间继续阅读了。下文更多的是关注内核空间的分配，但至少也会把用户空间的分配状况说清楚。

对于x86系统来讲，4G的内存空间被分为用户空间(e.g.,0-3G,0xC0000000)与内核空间(e.g.,3G-4G)，用户程序只能在进行系统调用时才能访问到内核空间。此外，当进程切换时，用户空间会随着进程的变化切换到对应进程的用户空间，而内核空间不会随着进程而改变，由内核负责映射。内核空间有本身对应的页表，而用户进程各自有不一样的页表。

从用户层向内核看，内存的地址形式依次是，逻辑地址--线性地址--物理地址，但Linux并无充分利用段机制，而是将全部程序的段地址固定在0-4G,所以逻辑地址就等于线性地址。

了解这些基本知识以后，来看看进程的虚拟地址是如何组织的。
一个进程的虚拟地址空间主要由两个数据结构来描述，mm_struct与vm_area_struct。 来具体说说这两个结构体用来作什么

每一个进程有一个mm_struct结构，在进程的task_struct结构体中有一个指针指向mm_struct。 mm_struct的定义以下：

struct mm_struct {

struct vm_area_struct * mmap; /* 指向虚拟区间（VMA）链表 */

rb_root_t mm_rb; ／*指向red_black树*/

struct vm_area_struct * mmap_cache; /* 指向最近找到的虚拟区间*/

pgd_t * pgd; ／*指向进程的页目录*/

atomic_t mm_users; /* 用户空间中的有多少用户*/

atomic_t mm_count; /* 对"struct mm_struct"有多少引用*/

int map_count; /* 虚拟区间的个数*/

struct rw_semaphore mmap_sem;

spinlock_t page_table_lock; /* 保护任务页表和 mm->rss */

struct list_head mmlist; /*全部活动（active）mm的链表 */

unsigned long start_code, end_code, start_data, end_data;

unsigned long start_brk, brk, start_stack;

unsigned long arg_start, arg_end, env_start, env_end;

unsigned long rss, total_vm, locked_vm;

unsigned long def_flags;

unsigned long cpu_vm_mask;

unsigned long swap_address;

 

unsigned dumpable:1;

 

/* Architecture-specific MM context */

mm_context_t context;

};

简单来讲，mm_struct是对整个进程的用户空间的描述，而进程的虚拟空间可能有多个虚拟区间(这里的区间就是由vm_area_struct来描述). vm_area_struct是描述进程虚拟空间的基本单元，那这些基本单元又是如何管理组织的呢？内核采起两种方式来组织这些基本单元，第一，正如mm_struct中的mmap指针指向vm_area_struct，以链表形式存储，这种结构主要用来遍历节点；第二，以红黑树来组织vm_area_struct，这种结构主要在定位特定
内存区域时用来搜索，以下降耗时。

了解了这些关联以后，回到最前面，当你写的用户程序在申请内存时(e.g., int i =0; malloc())，注意这里申请的内存仍是虚拟内存，能够说是“内存区域”(vm_area_struct)，并不是实际物理内存。 这些虚拟内存除了malloc()方式(由专门的brk()系统调用实现)，最终都是经过系统调用mmap来完成的，而mmap系统调用对应的服务例程是do_mmap()函数，有关do_mmap()函数，可参考do_mmap().

说了这么多用户空间，该把重心来看看内核空间了。
用户空间有malloc内存分配函数，内核空间一样有相似的内存分配函数，只是种类多一些(e.g.,*kmalloc/kfree,vmalloc/vfree,kmem_cache_alloc/kmem_cache_free,get_free_page).
在具体解释内核空间层的内存分配函数以前，先来看看，物理内存是如何组织的。Linux经过分页机制来管理物理内存，页面是物理内存的基本单位，每一个页面占4kB。页面在系统中由struct page结构来描述，而全部的struct page结构体都存储在数组mem_map[]中，所以只要能找到mem_map[]数组的物理地址，就能遍历全部页面的地址。能够来大体看一下struct page*的定义：

struct page {

unsigned long flags;

atomic_t count;

unsigned int mapcount;

unsigned long private;

struct address_space *mapping;

pgoff_t index;

struct list_head lru;

union{

struct pte_chain;

pte_addr_t;

}

void *virtual;

};

 

其中，flag用来存放页的状态，count记录该页面被引用了多少次，mapping指向该页面相关的地址空间对象… 这里只是一个简化的定义，真实状况会复杂一些，要把page说清楚，须要写一篇新的博客了，以后的文章会专门介绍。须要注意的是，page描述的是物理内存自己，而并不是包含在里面的数据。

那这些page又和内核空间的内存分配有什么关系呢？
内核空间有一系列的页面分配函数：

struct page * alloc_page(unsigned int gfp_mask)

//Allocate a single page and return a struct address

 

struct page * alloc_pages(unsigned int gfp_mask, unsigned int order)

//Allocate 2order number of pages and returns a struct page

 

unsigned long get_free_page(unsigned int gfp_mask)

//Allocate a single page, zero it and return a virtual address

 

unsigned long __get_free_page(unsigned int gfp_mask)

//Allocate a single page and return a virtual address

 

unsigned long __get_free_pages(unsigned int gfp_mask, unsigned int order)

//Allocate 2order number of pages and return a virtual address

 

struct page * __get_dma_pages(unsigned int gfp_mask, unsigned int order)

//Allocate 2order number of pages from the DMA zone and return a struct

 

以_ _get_free_pages为例看看其函数间调用关系：

unsigned long __get_free_pages(gfp_t gfp_mask, unsigned int order)

{

page = alloc_pages(gfp_mask, order);

}

#define alloc_pages(gfp_mask, order) \ alloc_pages_node(numa_node_id(), gfp_mask, order)

 

static inline struct page *alloc_pages_node(int nid, gfp_t gfp_mask,unsigned int order)

{

return __alloc_pages_node(nid, gfp_mask, order);

}

 

static inline struct page * __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)

{

 

return __alloc_pages(gfp_mask, order, node_zonelist(nid, gfp_mask));

}

 

最终_ _get_free_page会调用_ _alloc_pages函数分配页面。_ _alloc_pages是全部页面分配函数的核心函数，最终都会调用到这个函数，它会返回一个struct page结构。

在了解与其它内存分配函数的区别前，先说明下面这个概念

前文说过3G-4G属于内核空间，而后在内核空间中又有进一步划分。
3G~vmalloc_start这段地址是物理内存映射区域，该区域包括了内核镜像，mem_map数组等等。在vmalloc_start~vmalloc_end属于vmalloc区域（vmalloc下文会说),vmalloc_end的位置接近4G(最后系统会保留一片128KB大小的区域专用页面映射). 那这个vmalloc_start的位置又在哪呢？假设咱们使用的系统内存是512M,vmalloc_start就在应在3G+512M附近（说”附近”由于是在物理内存映射区与vmalloc_start期间还会存在一个8M大小的gap来防止跃界）.固然实际状况都比这个大，甚至都4G，8G，16G..但咱们使用的CPU都是64位的，可寻址空间就不止4G了，这个理论仍然有效。

_ _get_free_page系列函数申请的内存位于物理内存映射区域，在物理上是连续的，注意，函数返回的是虚拟地址，其与物理地址有一个固定的偏移，存在比较简单的转换关系，virt_to_phys()函数作的就是这件事：

#define __pa(x) ((unsigned long)(x)-PAGE_OFFSET)

extern inline unsigned long virt_to_phys(volatile void * address)

{

　 return __pa(address);

}

 

注意，这里的PAGE_OFFSET指的就是3G(针对x86位系统).

与页面分配系函数同样，kmalloc函数申请的内存也处于物理内存映射区域，在物理上是连续的。Kmalloc函数是slab分配器提供的分配内存的接口，slab是什么？这里不去具体讲slab分配原理,想详细了解的slab能够参考这里. 简单说明一下：slab是为了不内部碎片使得一个页面内包含的众多小块内存可独立被分配使用，是为分配小内存提供的一种高效机制。追踪kmalloc函数，能够发现，它最终仍是调用前面提到的
_ _alloc_pages()函数。既然kmalloc基于slab实现，而slab分配机制又不是独立的，自己也是在以页面为单位分配的基础上来划分更细粒度的内存供调用者使用。就是说系统先用页分配器分配以页为最小单位的连续物理地 址，而后kmalloc再在这上面根据调用者的须要进行切分。

既然slab是为了解决内部碎片的问题，那想必也有一个解决外部碎片的机制(注：外部分片是指系统虽有足够的内存，但倒是分散的碎片，没法知足对大块“连续内存”的需求)。没错，伙伴关系系统就是这么一个机制。伙伴关系系统提供vmalloc来分配非连续内存,其分配的地址限于上述说的vmalloc_start~vmalloc_end之间。这些虚拟地址与物理内存没有简单的位移关系，必须经过内核页表才可转换为物理地址或物理页。它们有可能还没有被映射，在发生缺页时才真正分配物理页面。

说到这里，还有一个关键函数没提，kmem_cache_alloc。 kmem_cache_alloc也是基于slab分配器的一种内存分配方式，适用于反复分配同一大小内存块的场合。首先用kmem_cache_create建立一个高速缓存区域，而后用kmem_cache_alloc从该高速缓存区域获取新的内存块。kmem_cache_alloc分配固定大小的内存块。kmalloc则是在kmem_cache_create的基础实现的，其分配动态大小的内存块，查看源码能够发现kmalloc函数中会有一段代码块转向调用kmem_cache_alloc：

static inline void *kmalloc(size_t size, gfp_t flags)

{

if (__builtin_constant_p(size)) {

int i = 0;

#define CACHE(x) \

if (size <= x) \

goto found; \

else \

i++;

#include "kmalloc_sizes.h"

#undef CACHE

{

extern void __you_cannot_kmalloc_that_much(void);

__you_cannot_kmalloc_that_much();

}

found:

return kmem_cache_alloc((flags & GFP_DMA) ?

malloc_sizes[i].cs_dmacachep :

malloc_sizes[i].cs_cachep, flags);

}

return __kmalloc(size, flags);

}

内核空间经常使用的内存分配函数就此说完了，实际除了这些经常使用的，还有其它的分配函数，在此简单说明一下。如， dma_alloc_coherent，基于 _ _alloc_pages实现，适用于DMA操做； ioremap,实现已知物理地址到虚拟地址的映射，适用于物理地址已经的场合，如设备驱动； alloc_bootmem，在启动内核时，预留一段内存，内核看不见，对内存管理要求较高。

 

 

 

 

 

 

 

Linux内存管理原理

本文以32位机器为准，串讲一些内存管理的知识点。

 

1. 虚拟地址、物理地址、逻辑地址、线性地址

　虚拟地址又叫线性地址。linux没有采用分段机制，因此逻辑地址和虚拟地址（线性地址）（在用户态，内核态逻辑地址专指下文说的线性偏移前的地址）是一个概念。物理地址自没必要提。内核的虚拟地址和物理地址，大部分只差一个线性偏移量。用户空间的虚拟地址和物理地址则采用了多级页表进行映射，但仍称之为线性地址。

2. DMA/HIGH_MEM/NROMAL 分区

在x86结构中，Linux内核虚拟地址空间划分0~3G为用户空间，3~4G为内核空间(注意，内核能够使用的线性地址只有1G)。内核虚拟空间（3G~4G）又划分为三种类型的区：
ZONE_DMA 3G以后起始的16MB
ZONE_NORMAL 16MB~896MB
ZONE_HIGHMEM 896MB ~1G

因为内核的虚拟和物理地址只差一个偏移量：物理地址 = 逻辑地址 – 0xC0000000。因此若是1G内核空间彻底用来线性映射，显然物理内存也只能访问到1G区间，这显然是不合理的。HIGHMEM就是为了解决这个问题，专门开辟的一块没必要线性映射，能够灵活定制映射，以便访问1G以上物理内存的区域。从网上扣来一图，

高端内存的划分，又以下图，

内核直接映射空间 PAGE_OFFSET~VMALLOC_START，kmalloc和__get_free_page()分配的是这里的页面。两者是借助slab分配器，直接分配物理页再转换为逻辑地址（物理地址连续）。适合分配小段内存。此区域 包含了内核镜像、物理页框表mem_map等资源。

内核动态映射空间 VMALLOC_START~VMALLOC_END，被vmalloc用到，可表示的空间大。

内核永久映射空间 PKMAP_BASE ~ FIXADDR_START，kmap

内核临时映射空间 FIXADDR_START~FIXADDR_TOP，kmap_atomic

3.伙伴算法和slab分配器

伙伴Buddy算法解决了外部碎片问题.内核在每一个zone区管理着可用的页面，按2的幂级（order）大小排成链表队列，存放在free_area数组。

具体buddy管理基于位图，其分配回收页面的算法描述以下，

buddy算法举例描述:

假设咱们的系统内存只有16个页面RAM。由于RAM只有16个页面，咱们只需用四个级别（orders）的伙伴位图（由于最大连续内存大小为16个页面），以下图所示。

 

 

order（0）bimap有8个bit位（页面最多16个页面，因此16/2）

order（1）bimap有4个bit位（order（0）bimap有8个bit位，因此8/2）；

也就是order（1）第一块由两个页框page1 与page2组成与order（1）第2块由两个页框page3 与page4组成，这两个块之间有一个bit位

order（2）bimap有2个bit位（order（1）bimap有4个bit位，因此4/2）

order（3）bimap有1个bit位（order（2）bimap有4个bit位，因此2/2）

在order（0），第一个bit表示开始的2个页面，第二个bit表示接下来的2个页面，以此类推。由于页面4已分配，而页面5空闲，故第三个bit为1。

一样在order（1）中，bit3是1的缘由是一个伙伴彻底空闲（页面8和9），和它对应的伙伴（页面10和11）却并不是如此，故之后回收页面时，能够合并。

分配过程

当咱们须要order（1）的空闲页面块时，则执行如下步骤：

一、初始空闲链表为：

order(0): 5, 10

order(1): 8 [8,9]

order(2): 12 [12,13,14,15]

order(3):

二、从上面空闲链表中，咱们能够看出，order（1）链表上，有一个空闲的页面块，把它分配给用户，并从该链表中删除。

三、当咱们再须要一个order（1）的块时，一样咱们从order（1）空闲链表上开始扫描。

四、若在order（1）上没有空闲页面块，那么咱们就到更高的级别（order）上找，order（2）。

五、此时（order（1）上没有空闲页面块）有一个空闲页面块，该块是从页面12开始。该页面块被分割成两个稍微小一些order（1）的页面块，[12，13]和[14，15]。[14，15]页面块加到order（1）空闲链表中，同时[12，13]页面块返回给用户。

六、最终空闲链表为：

order(0): 5, 10

order(1): 14 [14,15]

order(2):

order(3):

回收过程

当咱们回收页面11（order 0）时，则执行如下步骤：

1、找到在order（0）伙伴位图中表明页面11的位，计算使用下面公示：

index = page_idx >> (order + 1)

= 11 >> (0 + 1)

= 5

二、检查上面一步计算位图中相应bit的值。若该bit值为1，则和咱们临近的，有一个空闲伙伴。Bit5的值为1（注意是从bit0开始的，Bit5即为第6bit），由于它的伙伴页面10是空闲的。

三、如今咱们从新设置该bit的值为0，由于此时两个伙伴（页面10和页面11）彻底空闲。

四、咱们将页面10，从order（0）空闲链表中摘除。

五、此时，咱们对2个空闲页面（页面10和11，order（1））进行进一步操做。

六、新的空闲页面是从页面10开始的，因而咱们在order（1）的伙伴位图中找到它的索引，看是否有空闲的伙伴，以进一步进行合并操做。使用第一步中的计算公司，咱们获得bit 2（第3位）。

七、Bit 2（order（1）位图）一样也是1，由于它的伙伴页面块（页面8和9）是空闲的。

八、从新设置bit2（order（1）位图）的值，而后在order（1）链表中删除该空闲页面块。

九、如今咱们合并成了4页面大小（从页面8开始）的空闲块，从而进入另外的级别。在order（2）中找到伙伴位图对应的bit值，是bit1，且值为1，需进一步合并（缘由同上）。

十、从oder（2）链表中摘除空闲页面块（从页面12开始），进而将该页面块和前面合并获得的页面块进一步合并。如今咱们获得从页面8开始，大小为8个页面的空闲页面块。

十一、咱们进入另一个级别，order（3）。它的位索引为0，它的值一样为0。这意味着对应的伙伴不是所有空闲的，因此没有再进一步合并的可能。咱们仅设置该bit为1，而后将合并获得的空闲页面块放入order（3）空闲链表中。

十二、最终咱们获得大小为8个页面的空闲块，

 

buddy避免内部碎片的努力

物理内存的碎片化一直是Linux操做系统的弱点之一，尽管已经有人提出了不少解决方法，可是没有哪一个方法可以完全的解决，memory buddy分配就是解决方法之一。 咱们知道磁盘文件也有碎片化问题，可是磁盘文件的碎片化只会减慢系统的读写速度，并不会致使功能性错误，并且咱们还能够在不影响磁盘功能的前提的下，进行磁盘碎片整理。而物理内存碎片则大相径庭，物理内存和操做系统结合的太过于紧密，以致于咱们很难在运行时，进行物理内存的搬移（这一点上，磁盘碎片要容易的多；实际上mel gorman已经提交了内存紧缩的patch，只是尚未被主线内核接收）。 所以解决的方向主要放在预防碎片上。在2.6.24内核开发期间，防止碎片的内核功能加入了主线内核。在了解反碎片的基本原理前，先对内存页面作个归类：

1. 不可移动页面 unmoveable：在内存中位置必须固定，没法移动到其余地方，核心内核分配的大部分页面都属于这一类。

2.  可回收页面 reclaimable：不能直接移动，可是能够回收，由于还能够从某些源重建页面，好比映射文件的数据属于这种类别，kswapd会按照必定的规则，周期性的回收这类页面。

3. 可移动页面 movable：能够随意的移动。属于用户空间应用程序的页属于此类页面，它们是经过页表映射的，所以咱们只须要更新页表项，并把数据复制到新位置就能够了，固然要注意，一个页面可能被多个进程共享，对应着多个页表项。

防止碎片的方法就是把这三类page放在不一样的链表上，避免不一样类型页面相互干扰。考虑这样的情形，一个不可移动的页面位于可移动页面中间，那么咱们移动或者回收这些页面后，这个不可移动的页面阻碍着咱们得到更大的连续物理空闲空间。

 

另外，每一个zone区都有一个本身的失活净页面队列，与此对应的是两个跨zone的全局队列，失活脏页队列 和 活跃队列。这些队列都是经过page结构的lru指针链入的。

思考：失活队列的意义是什么(见<linux内核源代码情景分析>)?

 

slab分配器：解决内部碎片问题

内核一般依赖于对小对象的分配，它们会在系统生命周期内进行无数次分配。slab  缓存分配器经过对相似大小（远小于1page）的对象进行缓存而提供这种功能，从而避免了常见的内部碎片问题。此处暂贴一图，关于其原理，常见参考文献3。很显然，slab机制是基于buddy算法的，前者是对后者的细化。

 

 

4.页面回收/侧重机制

关于页面的使用
在以前的一些文章中，咱们了解到linux内核会在不少状况下分配页面。
一、内核代码可能调用alloc_pages之类的函数，从管理物理页面的伙伴系统（管理区zone上的free_area空闲链表）上直接分配页面（见《linux内核内存管理浅析》）。好比：驱动程序可能用这种方式来分配缓存；建立进程时，内核也是经过这种方式分配连续的两个页面，做为进程的thread_info结构和内核栈；等等。从伙伴系统分配页面是最基本的页面分配方式，其余的内存分配都是基于这种方式的；
二、内核中的不少对象都是用slab机制来管理的（见《linux slub分配器浅析》）。slab就至关于对象池，它将页面“格式化”成“对象”，存放在池中供人使用。当slab中的对象不足时，slab机制会自动从伙伴系统中分配页面，并“格式化”成新的对象；
三、磁盘高速缓存（见《linux内核文件读写浅析》）。读写文件时，页面被从伙伴系统分配并用于磁盘高速缓存，而后磁盘上的文件数据被载入到对应的磁盘高速缓存页面中；
四、内存映射。这里所谓的内存映射其实是指将内存页面映射到用户空间，供用户进程使用。进程的task_struct->mm结构中的每个vma就表明着一个映射，而映射的真正实现则是在用户程序访问到对应的内存地址以后，由缺页异常引发的页面被分配和页表被更新（见《linux内核内存管理浅析》）；

页面回收简述
有页面分配，就会有页面回收。页面回收的方法大致上可分为两种：
一是主动释放。就像用户程序经过free函数释放曾经经过malloc函数分配的内存同样，页面的使用者明确知道页面何时要被使用，何时又再也不须要了。
上面提到的前两种分配方式，通常都是由内核程序主动释放的。对于直接从伙伴系统分配的页面，这是由使用者使用free_pages之类的函数主动释放的，页面释放后被直接放归伙伴系统；从slab中分配的对象（使用kmem_cache_alloc函数），也是由使用者主动释放的（使用kmem_cache_free函数）。

另外一种页面回收方式是经过linux内核提供的页框回收算法（PFRA）进行回收。页面的使用者通常将页面看成某种缓存，以提升系统的运行效率。缓存一直存在当然好，可是若是缓存没有了也不会形成什么错误，仅仅是效率受影响而已。页面的使用者不明确知道这些缓存页面何时最好被保留，何时最好被回收，这些都交由PFRA来关心。
简单来讲，PFRA要作的事就是回收这些能够被回收的页面。为了不系统陷入页面紧缺的困境，PFRA会在内核线程中周期性地被调用运行。或者因为系统已经页面紧缺，试图分配页面的内核执行流程由于得不到须要的页面，而同步地调用PFRA。
上面提到的后两种分配方式，通常是由PFRA来进行回收的（或者由相似删除文件、进程退出、这样的过程来同步回收）。

PFRA回收通常页面
而对于上面提到的前两种页面分配方式（直接分配页面和经过slab分配对象），也有可能须要经过PFRA来回收。
页面的使用者能够向PFRA注册回调函数（使用register_shrink函数）。而后由PFRA在适当的时机来调用这些回调函数，以触发对相应页面或对象的回收。
其中较为典型的是对dentry的回收。dentry是由slab分配的，用于表示虚拟文件系统目录结构的对象。在dentry的引用记数被减为0的时候，dentry并非直接被释放，而是被放到一个LRU链表中缓存起来，便于后续的使用。（见《linux内核虚拟文件系统浅析》。）
而这个LRU链表中的dentry最终是须要被回收的，因而虚拟文件系统在初始化时，调用register_shrinker注册了回收函数shrink_dcache_memory。
系统中全部文件系统的超级块对象被存放在一个链表中，shrink_dcache_memory函数扫描这个链表，获取每一个超级块的未被使用dentry的LRU，而后从中回收一些最老的dentry。随着dentry的释放，对应的inode将被减引用，也可能引发inode被释放。
inode被释放后也是放在一个未使用链表中，虚拟文件系统在初始化时还调用register_shrinker注册了回调函数shrink_icache_memory，用来回收这些未使用的inode，从而inode中关联的磁盘高速缓存也将被释放。

另外，随着系统的运行，slab中可能会存在不少的空闲对象（好比在对某一对象的使用高峰事后）。PFRA中的cache_reap函数就用于回收这些多余的空闲对象，若是某些空闲的对象正好可以还原成一个页面，则这个页面能够被释放回伙伴系统；
cache_reap函数要作的事情提及来很简单。系统中全部存放对象池的kmem_cache结构连成一个链表，cache_reap函数扫描其中的每个对象池，而后寻找能够回收的页面，并将其回收。（固然，实际的过程要更复杂一点。）

关于内存映射
前面说到，磁盘高速缓存和内存映射通常由PFRA来进行回收。PFRA对这二者的回收是很相似的，实际上，磁盘高速缓存极可能就被映射到了用户空间。下面简单对内存映射作一些介绍：

内存映射分为文件映射和匿名映射。
文件映射是指表明这个映射的vma对应到一个文件中的某个区域。这种映射方式相对较少被用户态程序显式地使用，用户态程序通常习惯于open一个文件、而后read/write去读写文件。
而实际上，用户程序也能够使用mmap系统调用将一个文件的某个部分映射到内存上（对应到一个vma），而后以访存的方式去读写文件。尽管用户程序较少这样使用，可是用户进程中却充斥着这样的映射：进程正在执行的可执行代码（包括可执行文件、lib库文件）就是以这样的方式被映射的。
在《linux内核文件读写浅析》一文中，咱们并无讨论关于文件映射的实现。实际上，文件映射是将文件的磁盘高速缓存中的页面直接映射到了用户空间（可见，文件映射的页面是磁盘高速缓存页面的子集），用户能够0拷贝地对其进行读写。而使用read/write的话，则会在用户空间的内存和磁盘高速缓存间发生一次拷贝。
匿名映射相对于文件映射，表明这个映射的vma没有对应到文件。对于用户空间普通的内存分配（堆空间、栈空间），都属于匿名映射。
显然，多个进程可能经过各自的文件映射来映射到同一个文件上（好比大多数进程都映射了libc库的so文件）；那匿名映射呢？实际上，多个进程也可能经过各自的匿名映射来映射到同一段物理内存上，这种状况是因为fork以后父子进程共享原来的物理内存（copy-on-write）而引发的。

文件映射又分为共享映射和私有映射。私有映射时，若是进程对映射的地址空间进行写操做，则映射对应的磁盘高速缓存并不会直接被写。而是将原有内容复制一份，而后再写这个复制品，而且当前进程的对应页面映射将切换到这个复制品上去（写时复制）。也就是说，写操做是只有本身可见的。而对于共享映射，写操做则会影响到磁盘高速缓存，是你们均可见的。

哪些页面该回收
至于回收，磁盘高速缓存的页面（包括文件映射的页面）都是能够被丢弃并回收的。可是若是页面是脏页面，则丢弃以前必须将其写回磁盘。
而匿名映射的页面则都是不能够丢弃的，由于页面里面存有用户程序正在使用的数据，丢弃以后数据就无法还原了。相比之下，磁盘高速缓存页面中的数据自己是保存在磁盘上的，能够复现。
因而，要想回收匿名映射的页面，只好先把页面上的数据转储到磁盘，这就是页面交换（swap）。显然，页面交换的代价相对更高一些。
匿名映射的页面能够被交换到磁盘上的交换文件或交换分区上（分区便是设备，设备即也是文件。因此下文统称为交换文件）。

因而，除非页面被保留或被上锁（页面标记PG_reserved/PG_locked被置位。某些状况下，内核须要暂时性地将页面保留，避免被回收），全部的磁盘高速缓存页面均可回收，全部的匿名映射页面均可交换。

尽管能够回收的页面不少，可是显然PFRA应当尽量少地去回收/交换（由于这些页面要从磁盘恢复，须要很大的代价）。因此，PFRA仅当必要时才回收/交换一部分不多被使用的页面，每次回收的页面数是一个经验值：32。

因而，全部这些磁盘高速缓存页面和匿名映射页面都被放到了一组LRU里面。（实际上，每一个zone就有一组这样的LRU，页面都被放到本身对应的zone的LRU中。）
一组LRU由几对链表组成，有磁盘高速缓存页面（包括文件映射页面）的链表、匿名映射页面的链表、等。一对链表其实是active和inactive两个链表，前者是最近使用过的页面、后者是最近未使用的页面。
进行页面回收的时候，PFRA要作两件事情，一是将active链表中最近最少使用的页面移动到inactive链表、二是尝试将inactive链表中最近最少使用的页面回收。

肯定最近最少使用
如今就有一个问题了，怎么肯定active/inactive链表中哪些页面是最近最少使用的呢？
一种方法是排序，当页面被访问时，将其移动到链表的尾部（假设回收从头部开始）。可是这就意味着页面在链表中的位置可能频繁移动，而且移动以前还必须先上锁（可能有多个CPU在同时访问），这样作对效率影响很大。
linux内核采用的是标记加顺序的办法。当页面在active和inactive两个链表之间移动时，老是将其放到链表的尾部（同上，假设回收从头部开始）。
页面没有在链表间移动时，并不会调整它们的顺序。而是经过访问标记来表示页面是否刚被访问过。若是inactive链表中已设置访问标记的页面再被访问，则将其移动到active链表中，而且清除访问标记。（实际上，为了不访问冲突，页面并不会直接从inactive链表移动到active链表，而是有一个pagevec中间结构用做缓冲，以免锁链表。）

页面的访问标记有两种状况，一是放在page->flags中的PG_referenced标记，在页面被访问时该标记置位。对于磁盘高速缓存中（未被映射）的页面，用户进程经过read、write之类的系统调用去访问它们，系统调用代码中会将对应页面的PG_referenced标记置位。
而对于内存映射的页面，用户进程能够直接访问它们（不通过内核），因此这种状况下的访问标记不是由内核来设置的，而是由mmu。在将虚拟地址映射成物理地址后，mmu会在对应的页表项上置一个accessed标志位，表示页面被访问。（一样的道理，mmu会在被写的页面所对应的页表项上置一个dirty标志，表示页面是脏页面。）
页面的访问标记（包括上面两种标记）将在PFRA处理页面回收的过程当中被清除，由于访问标记显然是应该有有效期的，而PFRA的运行周期就表明这个有效期。page->flags中的PG_referenced标记能够直接清除，而页表项中的accessed位则须要经过页面找到其对应的页表项后才能清除（见下文的“反向映射”）。

那么，回收过程又是怎样扫描LRU链表的呢？
因为存在多组LRU（系统中有多个zone，每一个zone又有多组LRU），若是PFRA每次回收都扫描全部的LRU找出其中最值得回收的若干个页面的话，回收算法的效率显然不够理想。
linux内核PFRA使用的扫描方法是：定义一个扫描优先级，经过这个优先级换算出在每一个LRU上应该扫描的页面数。整个回收算法以最低的优先级开始，先扫描每一个LRU中最近最少使用的几个页面，而后试图回收它们。若是一遍扫描下来，已经回收了足够数量的页面，则本次回收过程结束。不然，增大优先级，再从新扫描，直到足够数量的页面被回收。而若是始终不能回收足够数量的页面，则优先级将增长到最大，也就是全部页面将被扫描。这时，就算回收的页面数量仍是不足，回收过程都会结束。

每次扫描一个LRU时，都从active链表和inactive链表获取当前优先级对应数目的页面，而后再对这些页面作处理：若是页面不能被回收（如被保留或被上锁），则放回对应链表头部（同上，假设回收从头部开始）；不然若是页面的访问标记置位，则清除该标记，并将页面放回对应链表尾部（同上，假设回收从头部开始）；不然页面将从active链表被移动到inactive链表、或从inactive链表被回收。

被扫描到的页面根据访问标记是否置位来决定其去留。那么这个访问标记是如何设置的呢？有两个途径，一是用户经过read/write之类的系统调用访问文件时，内核操做磁盘高速缓存中的页面，会设置这些页面的访问标记（设置在page结构中）；二是进程直接访问已映射的页面时，mmu会自动给对应的页表项加上访问标记（设置在页表的pte中）。关于访问标记的判断就基于这两个信息。（给定一个页面，可能有多个pte引用到它。如何知道这些pte是否被设置了访问标记呢？那就须要经过反向映射找到这些pte。下面会讲到。）
PFRA不倾向于从active链表回收匿名映射的页面，由于用户进程使用的内存通常相对较少，且回收的话须要进行交换，代价较大。因此在内存剩余较多、匿名映射所占比例较少的状况下，都不会去回收匿名映射对应的active链表中的页面。（而若是页面已经被放到inactive链表中，就再也不去管那么多了。）

反向映射
像这样，在PFRA处理页面回收的过程当中，LRU的inactive链表中的某些页面可能就要被回收了。
若是页面没有被映射，直接回收到伙伴系统便可（对于脏页，先写回、再回收）。不然，还有一件麻烦的事情要处理。由于用户进程的某个页表项正引用着这个页面呢，在回收页面以前，还必须给引用它的页表项一个交待。
因而，问题就来了，内核怎么知道这个页面被哪些页表项所引用呢？为了作到这一点，内核创建了从页面到页表项的反向映射。
经过反向映射能够找到一个被映射的页面对应的vma，经过vma->vm_mm->pgd就能找到对应的页表。而后经过page->index获得页面的虚拟地址。再经过虚拟地址从页表中找到对应的页表项。（前面说到的获取页表项中的accessed标记，就是经过反向映射实现的。）

页面对应的page结构中，page->mapping若是最低位置位，则这是一个匿名映射页面，page->mapping指向一个anon_vma结构；不然是文件映射页面，page->mapping文件对应的address_space结构。（显然，anon_vma结构和address_space结构在分配时，地址必需要对齐，至少保证最低位为0。）
对于匿名映射的页面，anon_vma结构做为一个链表头，将映射这个页面的全部vma经过vma->anon_vma_node链表指针链接起来。每当一个页面被（匿名）映射到一个用户空间时，对应的vma就被加入这个链表。
对于文件映射的页面，address_space结构除了维护了一棵用于存放磁盘高速缓存页面的radix树，还为该文件映射到的全部vma维护了一棵优先搜索树。由于这些被文件映射到的vma并不必定都是映射整个文件，极可能只映射了文件的一部分。因此，这棵优先搜索树除了索引到全部被映射的vma，还要能知道文件的哪些区域是映射到哪些vma上的。每当一个页面被（文件）映射到一个用户空间时，对应的vma就被加入这个优先搜索树。因而，给定磁盘高速缓存上的一个页面，就能经过page->index获得页面在文件中的位置，就能经过优先搜索树找出这个页面映射到的全部vma。

上面两步中，神奇的page->index作了两件事，获得页面的虚拟地址、获得页面在文件磁盘高速缓存中的位置。
vma->vm_start记录了vma的首虚拟地址，vma->vm_pgoff记录了该vma在对应的映射文件（或共享内存）中的偏移，而page->index记录了页面在文件（或共享内存）中的偏移。
经过vma->vm_pgoff和page->index能获得页面在vma中的偏移，加上vma->vm_start就能获得页面的虚拟地址；而经过page->index就能获得页面在文件磁盘高速缓存中的位置。

页面换入换出
在找到了引用待回收页面的页表项后，对于文件映射，能够直接把引用该页面的页表项清空。等用户再访问这个地址的时候触发缺页异常，异常处理代码再从新分配一个页面，并去磁盘里面把对应的数据读出来就好了（说不定，页面在对应的磁盘高速缓存里面已经有了，由于其余进程先访问过）。这就跟页面映射之后，第一次被访问的情形同样；
对于匿名映射，先将页面写回到交换文件，而后还得在页表项中记录该页面在交换文件中的index。
页表项中有一个present位，若是该位被清除，则mmu认为页表项无效。在页表项无效的状况下，其余位不被mmu关心，能够用来存储其余信息。这里就用它们来存储页面在交换文件中的index了（其实是交换文件号+交换文件内的索引号）。

将匿名映射的页面交换到交换文件的过程（换出过程）与将磁盘高速缓存中的脏页写回文件的过程很类似。
交换文件也有其对应的address_space结构，匿名映射的页面在换出时先被放到这个address_space对应磁盘高速缓存中，而后跟脏页写回同样，被写回到交换文件中。写回完成后，这个页面才被释放（记住，咱们的目的是要释放这个页面）。
那么为何不直接把页面写回到交换文件，而要通过磁盘高速缓存呢？由于，这个页面可能被映射了屡次，不可能一次性把全部用户进程的页表中对应的页表项都修改好（修改为页面在交换文件中的索引），因此在页面被释放的过程当中，页面被暂时放在磁盘高速缓存上。
而并非全部页表项的修改过程都是能成功的（好比在修改以前页面又被访问了，因而如今又不须要回收这个页面了），因此页面放到磁盘高速缓存的时间也可能会很长。

一样，将匿名映射的页面从交换文件读出的过程（换入过程）也与将文件数据读出的过程很类似。
先去对应的磁盘高速缓存上看看页面在不在，不在的话再去交换文件里面读。文件里的数据也是被读到磁盘高速缓存中的，而后用户进程的页表中对应的页表项将被改写，直接指向这个页面。
这个页面可能不会立刻从磁盘高速缓存中拿下来，由于若是还有其余用户进程也映射到这个页面（它们的对应页表项已经被修改为了交换文件的索引），他们也能够引用到这里。直到没有其余的页表项再引用这个交换文件索引时，页面才能够从磁盘高速缓存中被取下来。

最后的必杀
前面说到，PFRA可能扫描了全部的LRU还没办法回收须要的页面。一样，在slab、dentry cache、inode cache、等地方，可能也没法回收到页面。
这时，若是某段内核代码必定要得到页面呢（没有页面，系统可能就要崩溃了）？PFRA只好使出最后的必杀技——OOM（out of memory）。所谓的OOM就是寻找一个最不重要的进程，而后将其杀死。经过释放这个进程所占有的内存页面，以缓解系统压力。

5.内存管理架构

针对上图，说几句，

[地址映射](图：左中)
linux内核使用页式内存管理，应用程序给出的内存地址是虚拟地址，它须要通过若干级页表一级一级的变换，才变成真正的物理地址。
想一下，地址映射仍是一件很恐怖的事情。当访问一个由虚拟地址表示的内存空间时，须要先通过若干次的内存访问，获得每一级页表中用于转换的页表项（页表是存放在内存里面的），才能完成映射。也就是说，要实现一次内存访问，实际上内存被访问了N+1次（N=页表级数），而且还须要作N次加法运算。
因此，地址映射必需要有硬件支持，mmu（内存管理单元）就是这个硬件。而且须要有cache来保存页表，这个cache就是TLB（Translation lookaside buffer）。
尽管如此，地址映射仍是有着不小的开销。假设cache的访存速度是内存的10倍，命中率是40%，页表有三级，那么平均一次虚拟地址访问大概就消耗了两次物理内存访问的时间。
因而，一些嵌入式硬件上可能会放弃使用mmu，这样的硬件可以运行VxWorks（一个很高效的嵌入式实时操做系统）、linux（linux也有禁用mmu的编译选项）、等系统。
可是使用mmu的优点也是很大的，最主要的是出于安全性考虑。各个进程都是相互独立的虚拟地址空间，互不干扰。而放弃地址映射以后，全部程序将运行在同一个地址空间。因而，在没有mmu的机器上，一个进程越界访存，可能引发其余进程莫名其妙的错误，甚至致使内核崩溃。
在地址映射这个问题上，内核只提供页表，实际的转换是由硬件去完成的。那么内核如何生成这些页表呢？这就有两方面的内容，虚拟地址空间的管理和物理内存的管理。（实际上只有用户态的地址映射才须要管理，内核态的地址映射是写死的。）

[虚拟地址管理](图：左下)
每一个进程对应一个task结构，它指向一个mm结构，这就是该进程的内存管理器。（对于线程来讲，每一个线程也都有一个task结构，可是它们都指向同一个mm，因此地址空间是共享的。）
mm->pgd指向容纳页表的内存，每一个进程有自已的mm，每一个mm有本身的页表。因而，进程调度时，页表被切换（通常会有一个CPU寄存器来保存页表的地址，好比X86下的CR3，页表切换就是改变该寄存器的值）。因此，各个进程的地址空间互不影响（由于页表都不同了，固然没法访问到别人的地址空间上。可是共享内存除外，这是故意让不一样的页表可以访问到相同的物理地址上）。
用户程序对内存的操做（分配、回收、映射、等）都是对mm的操做，具体来讲是对mm上的vma（虚拟内存空间）的操做。这些vma表明着进程空间的各个区域，好比堆、栈、代码区、数据区、各类映射区、等等。
用户程序对内存的操做并不会直接影响到页表，更不会直接影响到物理内存的分配。好比malloc成功，仅仅是改变了某个vma，页表不会变，物理内存的分配也不会变。
假设用户分配了内存，而后访问这块内存。因为页表里面并无记录相关的映射，CPU产生一次缺页异常。内核捕捉异常，检查产生异常的地址是否是存在于一个合法的vma中。若是不是，则给进程一个"段错误"，让其崩溃；若是是，则分配一个物理页，并为之创建映射。

[物理内存管理](图：右上)
那么物理内存是如何分配的呢？
首先，linux支持NUMA（非均质存储结构），物理内存管理的第一个层次就是介质的管理。pg_data_t结构就描述了介质。通常而言，咱们的内存管理介质只有内存，而且它是均匀的，因此能够简单地认为系统中只有一个pg_data_t对象。
每一种介质下面有若干个zone。通常是三个，DMA、NORMAL和HIGH。
DMA：由于有些硬件系统的DMA总线比系统总线窄，因此只有一部分地址空间可以用做DMA，这部分地址被管理在DMA区域（这属因而高级货了）；
HIGH：高端内存。在32位系统中，地址空间是4G，其中内核规定3~4G的范围是内核空间，0~3G是用户空间（每一个用户进程都有这么大的虚拟空间）（图：中下）。前面提到过内核的地址映射是写死的，就是指这3~4G的对应的页表是写死的，它映射到了物理地址的0~1G上。（实际上没有映射1G，只映射了896M。剩下的空间留下来映射大于1G的物理地址，而这一部分显然不是写死的）。因此，大于896M的物理地址是没有写死的页表来对应的，内核不能直接访问它们（必需要创建映射），称它们为高端内存（固然，若是机器内存不足896M，就不存在高端内存。若是是64位机器，也不存在高端内存，由于地址空间很大很大，属于内核的空间也不止1G了）；
NORMAL：不属于DMA或HIGH的内存就叫NORMAL。
在zone之上的zone_list表明了分配策略，即内存分配时的zone优先级。一种内存分配每每不是只能在一个zone里进行分配的，好比分配一个页给内核使用时，最优先是从NORMAL里面分配，不行的话就分配DMA里面的好了（HIGH就不行，由于还没创建映射），这就是一种分配策略。
每一个内存介质维护了一个mem_map，为介质中的每个物理页面创建了一个page结构与之对应，以便管理物理内存。
每一个zone记录着它在mem_map上的起始位置。而且经过free_area串连着这个zone上空闲的page。物理内存的分配就是从这里来的，从 free_area上把page摘下，就算是分配了。（内核的内存分配与用户进程不一样，用户使用内存会被内核监督，使用不当就"段错误"；而内核则无人监督，只能靠自觉，不是本身从free_area摘下的page就不要乱用。）

[创建地址映射]
内核须要物理内存时，不少状况是整页分配的，这在上面的mem_map中摘一个page下来就行了。好比前面说到的内核捕捉缺页异常，而后须要分配一个page以创建映射。
说到这里，会有一个疑问，内核在分配page、创建地址映射的过程当中，使用的是虚拟地址仍是物理地址呢？首先，内核代码所访问的地址都是虚拟地址，由于CPU指令接收的就是虚拟地址（地址映射对于CPU指令是透明的）。可是，创建地址映射时，内核在页表里面填写的内容倒是物理地址，由于地址映射的目标就是要获得物理地址。
那么，内核怎么获得这个物理地址呢？其实，上面也提到了，mem_map中的page就是根据物理内存来创建的，每个page就对应了一个物理页。
因而咱们能够说，虚拟地址的映射是靠这里page结构来完成的，是它们给出了最终的物理地址。然而，page结构显然是经过虚拟地址来管理的（前面已经说过，CPU指令接收的就是虚拟地址）。那么，page结构实现了别人的虚拟地址映射，谁又来实现page结构本身的虚拟地址映射呢？没人可以实现。
这就引出了前面提到的一个问题，内核空间的页表项是写死的。在内核初始化时，内核的地址空间就已经把地址映射写死了。page结构显然存在于内核空间，因此它的地址映射问题已经经过“写死”解决了。
因为内核空间的页表项是写死的，又引出另外一个问题，NORMAL（或DMA）区域的内存可能被同时映射到内核空间和用户空间。被映射到内核空间是显然的，由于这个映射已经写死了。而这些页面也可能被映射到用户空间的，在前面提到的缺页异常的场景里面就有这样的可能。映射到用户空间的页面应该优先从HIGH区域获取，由于这些内存被内核访问起来很不方便，拿给用户空间再合适不过了。可是HIGH区域可能会耗尽，或者可能由于设备上物理内存不足致使系统里面根本就没有HIGH区域，因此，将NORMAL区域映射给用户空间是必然存在的。
可是NORMAL区域的内存被同时映射到内核空间和用户空间并无问题，由于若是某个页面正在被内核使用，对应的page应该已经从free_area被摘下，因而缺页异常处理代码中不会再将该页映射到用户空间。反过来也同样，被映射到用户空间的page天然已经从free_area被摘下，内核不会再去使用这个页面。

[内核空间管理](图：右下)
除了对内存整页的使用，有些时候，内核也须要像用户程序使用malloc同样，分配一块任意大小的空间。这个功能是由slab系统来实现的。
slab至关于为内核中经常使用的一些结构体对象创建了对象池，好比对应task结构的池、对应mm结构的池、等等。
而slab也维护有通用的对象池，好比"32字节大小"的对象池、"64字节大小"的对象池、等等。内核中经常使用的kmalloc函数（相似于用户态的malloc）就是在这些通用的对象池中实现分配的。
slab除了对象实际使用的内存空间外，还有其对应的控制结构。有两种组织方式，若是对象较大，则控制结构使用专门的页面来保存；若是对象较小，控制结构与对象空间使用相同的页面。
除了slab，linux 2.6还引入了mempool（内存池）。其意图是：某些对象咱们不但愿它会由于内存不足而分配失败，因而咱们预先分配若干个，放在mempool中存起来。正常状况下，分配对象时是不会去动mempool里面的资源的，照常经过slab去分配。到系统内存紧缺，已经没法经过slab分配内存时，才会使用 mempool中的内容。

[页面换入换出](图：左上)(图：右上)
页面换入换出又是一个很复杂的系统。内存页面被换出到磁盘，与磁盘文件被映射到内存，是很类似的两个过程（内存页被换出到磁盘的动机，就是从此还要从磁盘将其载回内存）。因此swap复用了文件子系统的一些机制。
页面换入换出是一件很费CPU和IO的事情，可是因为内存昂贵这一历史缘由，咱们只好拿磁盘来扩展内存。可是如今内存愈来愈便宜了，咱们能够轻松安装数G的内存，而后将swap系统关闭。因而swap的实现实在让人难有探索的欲望，在这里就不赘述了。（另见：《linux内核页面回收浅析》）

[用户空间内存管理]
malloc是libc的库函数，用户程序通常经过它（或相似函数）来分配内存空间。
libc对内存的分配有两种途径，一是调整堆的大小，二是mmap一个新的虚拟内存区域（堆也是一个vma）。
在内核中，堆是一个一端固定、一端可伸缩的vma（图：左中）。可伸缩的一端经过系统调用brk来调整。libc管理着堆的空间，用户调用malloc分配内存时，libc尽可能从现有的堆中去分配。若是堆空间不够，则经过brk增大堆空间。
当用户将已分配的空间free时，libc可能会经过brk减少堆空间。可是堆空间增大容易减少却难，考虑这样一种状况，用户空间连续分配了10块内存，前9块已经free。这时，未free的第10块哪怕只有1字节大，libc也不可以去减少堆的大小。由于堆只有一端可伸缩，而且中间不能掏空。而第10块内存就死死地占据着堆可伸缩的那一端，堆的大小无法减少，相关资源也无法归还内核。
当用户malloc一块很大的内存时，libc会经过mmap系统调用映射一个新的vma。由于对于堆的大小调整和空间管理仍是比较麻烦的，从新建一个vma会更方便（上面提到的free的问题也是缘由之一）。
那么为何不老是在malloc的时候去mmap一个新的vma呢？第一，对于小空间的分配与回收，被libc管理的堆空间已经可以知足须要，没必要每次都去进行系统调用。而且vma是以page为单位的，最小就是分配一个页；第二，太多的vma会下降系统性能。缺页异常、vma的新建与销毁、堆空间的大小调整、等等状况下，都须要对vma进行操做，须要在当前进程的全部vma中找到须要被操做的那个（或那些）vma。vma数目太多，必然致使性能降低。（在进程的vma较少时，内核采用链表来管理vma；vma较多时，改用红黑树来管理。）

[用户的栈]
与堆同样，栈也是一个vma（图：左中），这个vma是一端固定、一端可伸（注意，不能缩）的。这个vma比较特殊，没有相似brk的系统调用让这个vma伸展，它是自动伸展的。
当用户访问的虚拟地址越过这个vma时，内核会在处理缺页异常的时候将自动将这个vma增大。内核会检查当时的栈寄存器（如：ESP），访问的虚拟地址不能超过ESP加n（n为CPU压栈指令一次性压栈的最大字节数）。也就是说，内核是以ESP为基准来检查访问是否越界。
可是，ESP的值是能够由用户态程序自由读写的，用户程序若是调整ESP，将栈划得很大很大怎么办呢？内核中有一套关于进程限制的配置，其中就有栈大小的配置，栈只能这么大，再大就出错。
对于一个进程来讲，栈通常是能够被伸展得比较大（如：8MB）。然而对于线程呢？
首先线程的栈是怎么回事？前面说过，线程的mm是共享其父进程的。虽然栈是mm中的一个vma，可是线程不能与其父进程共用这个vma（两个运行实体显然不用共用一个栈）。因而，在线程建立时，线程库经过mmap新建了一个vma，以此做为线程的栈（大于通常为：2M）。
可见，线程的栈在某种意义上并非真正栈，它是一个固定的区域，而且容量颇有限。

 

 

参考文献：《伙伴算法》

　　　　　《避免物理内存碎片化》

　　　　　《slab分配器》

　　　　　《linux slub分配器浅析》

　　　　　《linux内存管理浅析》

　　　　　《linux页面回收浅析》