(转载) Linux内存管理

原文链接：http://bbs.chinaunix.net/thread-2055231-1-1.html

1. 内核初始化：

    * 内核建立好内核页目录页表数据库，假设物理内存大小为len，则建立了[3G--3G+len]::[0--len]这样的虚地址vaddr和物理地址paddr的线性对应关系；
    * 内核建立一个page数组，page数组和物理页面系列完全是线性对应，page用来管理该物理页面状态，每个物理页面的虚地址保存在page->virtual中；
    * 内核建立好一个free_list，将没有使用的物理页面对应的page放入其中，已经使用的就不用放入了；

    

 

线性映射简化了内核中虚拟地址和物理地址之间相互转化的工作

物理地址 <--> 虚拟地址
#define __pa(x) ((unsigned long)(x) & 0x3fffffff)
#define __va(x) ((void *)((unsigned long)(x) | 0xc0000000))

不完全映射1G，是因为要保留出一段空间来供动态映射所使用，大于896M的物理地址是没有写死的页表来对应的，内核不能直接访问它们（必须要建立映射），称它们为高端内存

2. 内核模块申请内存vaddr = get_free_pages(mask,order)：

    * 内存管理模块从free_list找到一个page，将page->virtual作为返回值，该返回值就是对应物理页面的虚地址；
    * 将page从free_list中脱离；
    * 模块使用该虚拟地址操作对应的物理内存；

3. 内核模块使用vaddr，例如执行指令mov(eax, vaddr)：

    * CPU获得vaddr这个虚地址，利用建立好的页目录页表数据库，找到其对应的物理内存地址；
    * 将eax的内容写入vaddr对应的物理内存地址内；

4. 内核模块释放内存free_pages(vaddr,order)：

    * 依据vaddr找到对应的page；
    * 将该page加入到free_list中；

5. 用户进程申请内存vaddr = malloc(size)：

    * 内存管理模块从用户进程内存空间(0--3G)中找到一块还没使用的空间vm_area_struct(start--end)；
    * 随后将其插入到task->mm->mmap链表中；

    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较多时，改用红黑树来管理。）

   还可以参看这一篇帖子：频繁分配释放内存导致的性能问题的分析

   http://blog.csdn.net/baiduforum/article/details/6100154

   这个帖子的核心意思是说，当需要频繁（每秒2000次）分配大内存（2M，6个page）时，如果使用mmap，则每次申请的6个page大小的VMA会产生6次缺页异常，但处理完了就把VMA释放了，下次又得重复这一过程。后果就是每秒都会产生1w次以上的缺页异常。所以在这种情况下，即使在代码里free了申请的空间，进程也要把这块空间拽住不放，而不是还给内核。

6. 用户进程写入vaddr(0-3G)，例如执行指令mov(eax, vaddr)：

    * CPU获得vaddr这个虚地址，该虚地址应该已经由glibc库设置好了，一定在3G一下的某个区域，根据CR3寄存器指向的current->pgd查当前进程的页目录页表数据库，发现该vaddr对应的页目录表项为0，故产生异常；
    * 在异常处理中，发现该vaddr对应的vm_area_struct已经存在，为vaddr对应的页目录表项分配一个页表；
    * 随后从free_list找到一个page，将该page对应的物理页面物理首地址赋给vaddr对应的页表表项，很明显，此时的vaddr和paddr不是线性对应关系了；
    * 将page从free_list中脱离；
    * 异常处理返回；
    * CPU重新执行刚刚发生异常的指令mov(eax, vaddr)；
    * CPU获得vaddr这个虚地址，根据CR3寄存器指向的current->pgd，利用建立好的页目录页表数据库，找到其对应的物理内存地址；
    * 将eax的内容写入vaddr对应的物理内存地址内；  

7. 用户进程释放内存vaddr，free(vaddr)：

    * 找到该vaddr所在的vm_area_struct；
    * 找到vm_area_struct:start--end对应的所有页目录页表项，清空对应的所有页表项；
    * 释放这些页表项指向物理页面所对应的page，并将这些page加入到free_list队列中；
    * 有必要还会清空一些页目录表项，并释放这些页目录表项指向的页表；
    * 从task->mm->mmap链中删除该vm_area_struct并释放掉；

综合说明：

    * 可用物理内存就是free_list中各page对应的物理内存；
    * 页目录页表数据库的主要目的是为CPU访问物理内存时转换vaddr-->paddr使用，分配以及释放内存时不会用到，但是需要内核内存管理系统在合适时机为CPU建立好该库；
    * 对于用户进程在6中获得的物理页面，有两个页表项对应，一个就是内核页目录页表数据库的某个pte[i ]，一个就是当前进程内核页目录页表数据库的某个 pte[j]，但是只有一个page和其对应。如果此时调度到其他进程，其他进程申请并访问某个内存，则不会涉及到该物理页面，因为其分配时首先要从 free_list中找一个page，而该物理页面对应的page已经从free_list中脱离出来了，因此不存在该物理页面被其他进程改写操作的情况。内核中通过get_free_pages等方式获取内存时，也不会涉及到该物理页面，原理同前所述。