从进程的角度看linux的内存管理系统

从进程的角度看linux的内存管理系统 关键字 mmap()

2007年10月01日 星期一 下午 10:48

 

mmap()调用了do_mmap()，后者用来合并或者创建一个新的vm_area_struct.

static inline unsigned long do_mmap(struct file *file, unsigned long addr,
           unsigned long len, unsigned long prot,
           unsigned long flag, unsigned long offset)

do_mmap()映射flie文件描述符开始，offset为偏移量，len为长度的一段内存到新 建的vm_area_strcut，prot为读写权限一类标志，flag为共享权限一类标志。此种情况称为文件映射，而将参数file设为NULL，将 offset设为0，这时称为“匿名映射”

匿名映射说白了就是分配内存,但和malloc不同的是，它可以指定起始地址，并且起始地址和长度页对齐，并且可以指定属性(只读，可写)

进程内存的分配与回收

创建进程fork()、程序载入execve()、映射文件mmap()、动态内存分配malloc()/brk()等进程相关操作都需要分配内存给进程。不过这时进程申请和获得的还不是实际内存，而是虚拟内存，准确的说是“内存区域”。进程对内存区域的分配最终多会归结到do_mmap（）函数上来（brk调用被单独以系统调用实现，不用do_mmap()），

内核使用do_mmap()函数创建一个新的线性地址区间。但是说该函数创建了一个新VMA并不非常准确，因为如果创建的地址区间和一个已经存在的地址区间相邻，并且它们具有相同的访问权限的话，那么两个区间将合并为一个。如果不能合并，那么就确实需要创建一个新的VMA了。但无论哪种情况， do_mmap()函数都会将一个地址区间加入到进程的地址空间中－－无论是扩展已存在的内存区域还是创建一个新的区域。

同样释放一个内存区域使用函数do_ummap(),它会销毁对应的内存区域。

如何由虚变实！

    从 上面已经看到进程所能直接操作的地址都为虚拟地址。当进程需要内存时，从内核获得的仅仅时虚拟的内存区域，而不是实际的物理地址，进程并没有获得物理内存 （物理页框——页的概念请大家参与硬件基础一章），获得的仅仅是对一个新的线性地址区间的使用权。实际的物理内存只有当进程真的去访问新获取的虚拟地址 时，才会由“请页机制”产生“缺页”异常，从而进入分配实际页框的例程。

虽 然应用程序操作的对象是映射到物理内存之上的虚拟内存，但是处理器直接操作的却是物理内存。所以当用程序访问一个虚拟地址时，首先必须将虚拟地址转化成物 理地址，然后处理器才能解析地址访问请求。地址的转换工作需要通过查询页表才能完成，概括的讲，地址转换需要将虚拟地址分段，使每段虚地址都作为一个索引 指向页表，而页表项则指向下一级别的页表或者指向最终的物理页面。

每个进程都有自己的页表。进程描述符号的pgd域指向的就是进程的页全局目录。

内核分配物理页为了尽量减少不连续情况，采用了“伙伴”关系来管理空闲页框。最小单位只能是2的幂倍页面大小。内核中分配空闲页框的基本函数是get_free_page/get_free_pages，它们或是分配单页或是分配指定的页框（2、4、8…512页）。

注意：get_free_page是在内核中分配内存，不同于malloc在用户空间中分配，malloc利用堆动态分配，实际上是调用brk()系统调用，该调用的作用是扩大或缩小进程堆空间（它会修改进程的brk域）。如果现有的内存区域不够容纳堆空间，则会以页面大小的倍数位单位，扩张或收缩对应的内存区域，但brk值并非以页面大小为倍数修改，而是按实际请求修改。因此Malloc在用户空间分配内存可以以字节为单位分配,但内核在内部仍然会是以页为单位分配的。

内核内存使用

Slab

    所谓尺有所 长，寸有所短。以页为最小单位分配内存对于内核管理系统物理内存来说的确比较方便，但内核自身最常使用的内存却往往是很小（远远小于一页）的内存块——比 如存放文件描述符、进程描述符、虚拟内存区域描述符等行为所需的内存都不足一页。这些用来存放描述符的内存相比页面而言，就好比是面包屑与面包。一个整页 中可以聚集多个这种这些小块内存；而且这些小块内存块也和面包屑一样频繁地生成/销毁。

  为了满足内核对这种小内存块的需要，Linux系统采用了一种被称为slab分配器的技术。Slab分配器的实现相当复杂，但原理不难，其核心思想就是“存储池”的运用。内存片段（小块内存）被看作对象，当被使用完后，并不直接释放而是被缓存到“存储池”里，留做下次使用，这无疑避免了频繁创建与销毁对象所带来的额外负载。

Slab技术不但避免了内存内部分片（下文将解释）带来的不便（引入Slab分配器的主要目的是为了减少对伙伴系统分配算法的调用次数——频繁分配和回收必然会导致内存碎片——难以找到大块连续的可用内存），而且可以很好利用硬件缓存提高访问速度。

    Slab并非是脱离伙伴关系而独立存在的一种内存分配方式，slab仍然是建立在页面基础之上，换句话说，Slab将页面（来自于伙伴关系管理的空闲页框链）撕碎成众多小内存块以供分配，slab中的对象分配和销毁使用kmem_cache_alloc与kmem_cache_free。