linux内核-----内存管理相关技术

一．内部碎片和外部碎片

内部碎片：是指已经分配给进程的存储块，但是由于多的并不使用它，而在进程占有这块存储块时，系统无法利用它，直到进程释放它。

外部碎片：处于任何两个已分配区域或页面之间的空闲存储块，这些存储块的总和可以满足要求，但是由于它们地址不连续或其他原因，使得系统无法满足当前申请。

内核应该为分配一组连续的页面建立一种健壮的、高效的分配策略，从本质上讲避免外部碎片方法有两种：

1.利用分页单元把一组非连续的空闲页映射到连续的线性地址区间

2.开发一种适当的技术，以避免为产生外部碎片。

伙伴系统：减轻外部碎片问题

linux内核的伙伴算法最大限度的减少了内存的碎片，其实应该说成是尽自己最大的努力减少了内存的碎片。其思想就是将物理内存分成11个块链表，每个链表包含的是大小为1,2,4,8...512,1024的连续页框块。举例来说要分配256个连续页框，会先到块大小为256的链表中查找空闲块，若有直接返回，若没有，去大小为512的链表中进行查找，将512大小块分为两部分，一部分返回，一部分插入256大小的链表中，若512大小的链表中还没有，到1024大小的链表中查找，取出256大小的块，将剩下的512,256的块分别插入到各个链表中，内存释放的过程则是相反的。最大能分配的块时1024*4KB，即4M。

在分配过程中由大块分解而成的小块中没有被分配的块将一直等着被分配的块被释放从而和其合并，合并的操作正是在页面释放的过程中，最终的结果就是相当与没有分解大块，伙伴系统一直在向这个结果收敛，这就是为何伙伴系统能避免碎片的原因。伙伴系统在分配和释放两个方向上执行分解和合并两个互逆的操作，如果一开始系统没有碎片，那么最终的碎片将最小化，因为互逆的操作将最大力度的抵消碎片的产生，这就是精髓了。

采用伙伴算法分配内存时，每次至少分配一个页面。但当请求分配的内存大小为几十个字节或几百个字节时应该如何处理？如何在一个页面中分配小的内存区，小内存区的分配所产生的内碎片又如何解决？Linux采用Slab。

slab技术：解决内部碎片

与传统的内存管理模式相比， slab缓存分配器提供了很多优点。首先，内核通常依赖于对小对象的分配，它们会在系统生命周期内进行无数次分配。slab缓存分配器通过对类似大小的对象进行缓存而提供这种功能，从而避免了常见的碎片问题。slab分配器还支持通用对象的初始化，从而避免了为同一目而对一个对象重复进行初始化。

Linux 所使用的 slab分配器的基础是 Jeff Bonwick为 SunOS 操作系统首次引入的一种算法。在内核中，会为有限的对象集（例如文件描述符和其他常见结构）分配大量内存。Jeff发现对内核中普通对象进行初始化所需的时间超过了对其进行分配和释放所需的时间。因此他的结论是不应该将内存释放回一个全局的内存池，而是将内存保持为针对特定目而初始化的状态。例如，如果内存被分配给了一个互斥锁，那么只需在为互斥锁首次分配内存时执行一次互斥锁初始化函数（mutex_init）即可。后续的内存分配不需要执行这个初始化函数，因为从上次释放和调用析构之后，它已经处于所需的状态中了。

kmalloc引入的目的:

内核为了提高一些常用的数据结构(一般大小远小于1个page)的内存使用效率(空间和时间上)，引入slab分配器(区别于伙伴系统算法)，slab分配器使用伙伴系统算法作为物理内存分的接口，但是对于slab分配器中的对象，内核释放这个对象之后，相应的物理内存并不释放，可以留给下一个可能的对象使用，这样可以提高经常使用的数据结构内存使用效率(否则导致内存碎片和让内核疲劳于不停的内存分配和释放)。对于每种常用的数据结构(比如skb_buff)，内核可以使用kmem_cache_create()创建一个专用的高速缓存，但是如果对这个存储区的请求并不是那么的频繁，可以考虑使用kmalloc从通用高速缓存分配按照几何分布的存储区(从32个字节，到128k)。

内核非连续内存分配（Vmalloc）：解决外部碎片问题

 

伙伴关系也好、slab技术也好，从内存管理理论角度而言目的基本是一致的，它们都是为了防止“分片”，不过分片又分为外部分片和内部分片之说，所谓内部分片是说系统为了满足一小段内存区（连续）的需要，不得不分配了一大区域连续内存给它，从而造成了空间浪费；外部分片是指系统虽有足够的内存，但却是分散的碎片，无法满足对大块“连续内存”的需求。无论何种分片都是系统有效利用内存的障碍。slab分配器使得含与一个页面内众多小块内存可独立被分配使用，避免了内部分片，节约了空闲内存。伙伴关系把内存块按大小分组管理，一定程度上减轻了外部分片的危害，因为页框分配不在盲目，而是按照大小依次有序进行，不过伙伴关系只是减轻了外部分片，但并未彻底消除。你自己笔画一下多次分配页框后，空闲内存的剩余情况吧。

所以避免外部分片的最终思路还是落到了如何利用不连续的内存块组合成“看起来很大的内存块”——这里的情况很类似于用户空间分配虚拟内存，内存逻辑上连续，其实影射到并不一定连续的物理内存上。Linux内核借用了这个技术，允许内核程序在内核地址空间中分配虚拟地址，同样也利用页表（内核页表）将虚拟地址影射到分散的内存页上。以此完美地解决了内核内存使用中的外部分片问题。内核提供vmalloc函数分配内核虚拟内存，该函数不同于kmalloc，它可以分配较Kmalloc大得多的内存空间（可远大于128K，但必须是页大小的倍数），但相比Kmalloc来说Vmalloc需要对内核虚拟地址进行重影射，必须更新内核页表，因此分配效率上要低一些（用空间换时间）

mmap技术：

采用共享内存通信的一个显而易见的好处是效率高，因为进程可以直接读写内存，而不需要任何数据的拷贝。对于像管道和消息队列等通信方式，则需要在内核和用户空间进行四次的数据拷贝，而共享内存则只拷贝两次数据：一次从输入文件到共享内存区，另一次从共享内存区到输出文件。实际上，进程之间在共享内存时，并不总是读写少量数据后就解除映射，有新的通信时，再重新建立共享内存区域。而是保持共享区域，直到通信完毕为止，这样，数据内容一直保存在共享内存中，并没有写回文件。共享内存中的内容往往是在解除映射时才写回文件的。因此，采用共享内存的通信方式效率是非常高的。  

 

进程与内存

进程如何使用内存？

毫无疑问所有进程（执行的程序）都必须占用一定数量的内存，它或是用来存放从磁盘载入的程序代码，或是存放取自用户输入的数据等等。不过进程对这些内存的管理方式因内存用途不一而不尽相同，有些内存是事先静态分配和统一回收的，而有些却是按需要动态分配和回收的。

对任何一个普通进程来讲，它都会涉及到5种不同的数据段。稍有编程知识的朋友都该能想到这几个数据段种包含有“程序代码段”、“程序数据段”、“程序堆栈段”等。不错，这几种数据段都在其中，但除了以上几种数据段之外，进程还另外包含两种数据段。下面我们来简单归纳一下进程对应的内存空间中所包含的5种不同的数据区。

代码段：代码段是用来存放可执行文件的操作指令，也就是说是它是可执行程序在内存种的镜像。代码段需要防止在运行时被非法修改，所以只准许读取操作，而不允许写入（修改）操作——它是不可写的。

数据段：数据段用来存放可执行文件中已初始化全局变量，换句话说就是存放程序静态分配的变量和全局变量。

BSS段：BSS段包含了程序中未初始化全局变量，在内存中 bss段全部置零。在映射时，将bss段的值全部映射到内存中的0页，其值全为0.

堆（heap）：堆是用于存放进程运行中被动态分配的内存段，它大小并不固定，可动态扩张或缩减。当进程调用malloc等函数分配内存时，新分配的内存就被动态添加到堆上（堆被扩张）；当利用free等函数释放内存时，被释放的内存从堆中被剔除（堆被缩减）

栈：栈是用户存放程序临时创建的局部变量，也就是说我们函数括弧“{}”中定义的变量（但不包括static声明的变量，static意味这在数据段中存放变量）。除此以外在函数被调用时，其参数也会被压入发起调用的进程栈中，并且待到调用结束后，函数的返回值也回被存放回栈中。由于栈的先进先出特点，所以栈特别方便用来保存/恢复调用现场。从这个意义上将我们可以把堆栈看成一个临时数据寄存、交换的内存区。

进程如何组织这些区域？

上述几种内存区域中数据段、BSS和堆通常是被连续存储的——内存位置上是连续的，而代码段和栈往往会被独立存放。有趣的是堆和栈两个区域关系很“暧昧”，他们一个向下“长”（i386体系结构中栈向下、堆向上），一个向上“长”，相对而生。但你不必担心他们会碰头，因为他们之间间隔很大（到底大到多少，你可以从下面的例子程序计算一下），绝少有机会能碰到一起。

下图简要描述了进程内存区域的分布：

从前面的例子，我们对进程使用的逻辑内存分布已经先睹为快。这部分我们就继续进入操作系统内核看看进程对内存具体是如何进行分配和管理的。

从用户向内核看，所使用的内存表象形式会依次经历“逻辑地址”——“线形地址”——“物理地址”几种形式（关于几种地址的解释在前面已经讲述了）。逻辑地址经段机制转化成线性地址；线性地址又经过页机制转化为物理地址。（但是我们要知道Linux系统虽然保留了段机制，但是将所有程序的段地址都定死为0-4G，所以虽然逻辑地址和线性地址是两种不同的地址空间，但在Linux中逻辑地址就等于线性地址，它们的值是一样的）。沿着这条线索，我们所研究的主要问题也就集中在下面几个问题。

1.进程空间地址如何管理？

2.进程地址如何映射到物理内存？

3.物理内存如何被管理？

进程内存空间

Linux操作系统采用虚拟内存管理技术，使得每个进程都有各自互不干涉的进程地址空间。该空间是块大小为4G的线性虚拟空间，用户所看到和接触的都是该虚拟地址，无法看到实际的物理内存地址。利用这种虚拟地址不但能起到保护操作系统的效果（用户不能直接访问物理内存），而且更重要的是用户程序可使用比实际物理内存更大的地址空间（具体的原因请看硬件基础部分）。

在讨论进程空间细节前，请大家这里先要澄清下面几个问题。

第一、4G的进程地址空间被人为的分为两个部分——用户空间与内核空间。用户空间从0到3G（0xC0000000），内核空间占据3G到4G。用户进程通常情况下只能访问用户空间的虚拟地址，不能访问内核空间虚拟地址。例外情况只有用户进程进行系统调用（代表用户进程在内核态执行）等时刻可以访问到内核空间。

第二、用户空间对应进程，所以每当进程切换，用户空间就会跟着变化；而内核空间是由内核负责映射，它并不会跟着进程改变，是固定的。内核空间地址有自己对应的页表（init_mm.pgd），用户进程各自有不同的页表（。

第三、每个进程的用户空间都是完全独立、互不相干的。不信的话，你可以把上面的程序同时运行10次（当然为了同时运行，让它们在返回前一同睡眠100秒吧），你会看到10个进程占用的线性地址一模一样。

进程内存的分配与回收

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

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

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

如何由虚变实！

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

该异常是虚拟内存机制赖以存在的基本保证——它会告诉内核去真正为进程分配物理页，并建立对应的页表，这之后虚拟地址才实实在在映射到了系统物理内存上。（当然如果页被换出到磁盘，也会产生缺页异常，不过这时不用再建立页表了）

这种请页机制把页框的分配推迟到不能再推迟为止，并不急于把所有的事情都一次做完（这中思想由点想涉及模式中的代理模式（proxy））。之所以能这么做是利用了内存访问的“局部性原理”，请页带来的好处是节约了空闲内存，提高了系统吞吐。要想更清楚的了解请页，可以看看《深入理解linux内核》一书。