linux内存管理浅析

 

[ 地址映射](图：左中)
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）。 可见，线程的栈在某种意义上并非真正栈，它是一个固定的区域，而且容量颇有限。