【操作系统—虚拟化】内存分段

与昊
English

介绍

利用基址和界限寄存器,操作系统很容易将不同进程重定位到不同的物理内存区域。但是,对于这些内存区域,栈和堆之间,有一大块“空闲”空间。栈和堆之间的空间并没有被进程使用,却依然占用了实际的物理内存。因此,简单的通过基址寄存器和界限寄存器实现的虚拟内存很浪费。

泛化的基址/界限

为了解决这个问题,分段(segmentation)的概念应运而生。这个想法很简单,在MMU中引入不止一个基址和界限寄存器对,而是给地址空间内的每个逻辑段(segment)一对。一个段只是地址空间里的一个连续定长的区域,在典型的地址空间里有3个逻辑不同的段:代码、栈和堆。分段的机制使得操作系统能够将不同的段放到不同的物理内存区域,从而避免了虚拟地址空间中的未使用部分占用物理内存。

我们来看一个例子,如图所示,64KB的物理内存中放置了3个段。

image.png

你会想到,需要MMU中的硬件结构来支持分段:在这种情况下,需要一组3对基址和界限寄存器。下表展示了上面的例子中的寄存器值,每个界限寄存器记录了一个段的大小。

image.png

引用的是哪个段

硬件在地址转换时使用段寄存器。它如何知道段内的偏移量,以及地址引用了哪个段?

一种常见的方式,有时称为显式(explicit)方式,就是用虚拟地址的开头几位来标识不同的段。在我们之前的例子中,有3个段,因此需要两位来标识。如果我们用14位虚拟地址的前两位来标识,那么虚拟地址如下所示:

image.png

前两位告诉硬件我们引用哪个段,剩下的12位是段内偏移。因此,硬件就用前两位来决定使用哪个段寄存器,然后用后12位作为段内偏移。偏移量与基址寄存器相加,硬件就得到了最终的物理地址。请注意,偏移量也简化了对段边界的判断。我们只要检查偏移量是否小于界限,大于界限的为非法地址。

上面使用两位来区分段,但实际只有3个段(代码、堆、栈),因此有一个段的地址空间被浪费。因此有些系统中会将堆和栈当作同一个段,因此只需要一位来做标识。

硬件还有其他方法来决定特定地址在哪个段。在隐式(implicit)方式中,硬件通过地址产生的方式来确定段。例如,如果地址由程序计数器产生(即它是指令获取),那么地址在代码段。如果基于栈或基址指针,它一定在栈段。其他地址则在堆段。

栈的问题

栈和其他的内存段有一点关键区别,就是它反向增长,因此地址转换必须有所不同。首先,我们需要一点硬件支持。除了基址和界限外,硬件还需要知道段的增长方向(用一位区分,比如1代表自小而大增长,0反之)。

支持共享

随着分段机制的不断改进,人们很快意识到,通过再多一点的硬件支持,就能实现新的效率提升。具体来说,要节省内存,有时候在地址空间之间共享(share)某些内存段是有用的。

为了支持共享,需要一些额外的硬件支持,这就是保护位(protection bit)。基本上就是为每个段增加了几个位,标识程序是否能够读写该段,或执行其中的代码。通过将代码段标记为只读,同样的代码可以被多个进程共享,而不用担心破坏隔离。虽然每个进程都认为自己独占这块内存,但操作系统秘密地共享了内存,进程不能修改这些内存,所以假象得以保持。

有了保护位,前面描述的硬件算法也必须改变。除了检查虚拟地址是否越界,硬件还需要检查特定访问是否允许。如果用户进程试图写入只读段,或从非执行段执行指令,硬件会触发异常,让操作系统来处理出错进程。

操作系统支持

分段也带来了一些新的问题。第一个是老问题:操作系统在上下文切换时应该做什么?答案显而易见:各个段寄存器中的内容必须保存和恢复。每个进程都有自己独立的虚拟地址空间,操作系统必须在进程运行前,确保这些寄存器被正确地赋值。

第二个问题更重要,即管理物理内存的空闲空间。新的地址空间被创建时,操作系统需要在物理内存中为它的段找到空间。之前,我们假设所有的地址空间大小相同,物理内存可以被认为是一些槽块,进程可以放进去。现在,每个进程都有一些段,每个段的大小也可能不同。

一般会遇到的问题是,物理内存很快充满了许多空闲空间的小洞,因而很难分配给新的段,或扩大已有的段。这种问题被称为外部碎片(external fragmentation)[R69],如图所示。

image.png

该问题的一种解决方案是紧凑(compact)物理内存,重新安排原有的段。例如,操作系统先终止运行的进程,将它们的数据复制到连续的内存区域中去,改变它们的段寄存器中的值,指向新的物理地址,从而得到了足够大的连续空闲空间。但是,内存紧凑成本很高,因为拷贝段是内存密集型的,一般会占用大量的处理器时间。

一种更简单的做法是利用空闲列表管理算法,试图保留大的内存块用于分配。相关的算法可能有成百上千种,包括传统的最优匹配(best-fit,从空闲链表中找最接近需要分配空间的空闲块返回)、最坏匹配(worst-fit)、首次匹配(first-fit)以及像伙伴算法(buddy algorithm)这样更复杂的算法。但遗憾的是,无论算法多么精妙,都无法完全消除外部碎片,因此,好的算法只是试图减小它。

空闲空间管理

我们暂且将对虚拟内存的讨论放在一边,先来讨论空闲空间管理(free-space management)的一些问题。在操作系统用分段(segmentation)的方式实现虚拟内存时,以及在用户级的内存分配库(如malloc()和free())中,需要管理的空闲空间由大小不同的单元构成。在这两种情况下,会出现外部碎片的问题,让管理变得较为困难。

假设

首先,我们假定基本的接口就像malloc()和free()提供的那样。具体来说,void * malloc(size t size)需要一个参数size,它是应用程序请求的字节数。函数返回一个指针,指向这样大小的一块空间。对应的函数void free(void *ptr)函数接受一个指针,释放对应的内存块。

进一步假设,我们主要关心的是外部碎片的问题,先将内部碎片问题置之脑后。我们还假设,内存一旦被分配给客户,就不可以被重定位到其他位置。最后我们假设,分配程序所管理的是连续的一块字节区域。

底层机制

分隔与合并

空闲列表包含一组元素,记录了堆中的哪些空间还没有分配。假设有下面的30字节的堆:

image.png

这个堆对应的空闲列表如下:

image.png

可以看出,任何大于10字节的分配请求都会失败(返回NULL),因为没有足够的连续可用空间。但是,如果申请小于10字节空间,会发生什么?假设我们只申请一个字节的内存,此时分配程序会执行所谓的分割(splitting)动作:它找到一块可以满足请求的空闲空间,将其分割,第一块返回给用户,第二块留在空闲列表中。在我们的例子中,假设这时遇到申请一个字节的请求,分配程序选择使用第二块空闲空间,对malloc()的调用会返回20(1字节分配区域的地址),空闲列表会变成这样:

image.png

许多分配程序中也有一种机制,名为合并(coalescing)。如果应用程序调用free(10),归还堆中间的空间,会发生什么?分配程序不只是简单地将这块空闲空间加入空闲列表,还会在释放一块内存时合并可用空间。通过合并,最后空闲列表应该像这样:

image.png

追踪已分配空间的大小

可以看到,free(void *ptr)接口没有块大小的参数。要完成这个任务,大多数分配程序都会在头结构(header)中保存一点额外的信息,它在内存中的位置通常就在返回的内存块之前。该头块中至少包含所分配空间的大小,它也可能包含一些额外的指针来加速空间释放,包含一个幻数来提供完整性检查,以及其他信息。我们假定,一个简单的头块包含了分配空间的大小和一个幻数:

typedef struct  header_t {
    int size;
    int magic;
} header_t;

在内存中看起来像是这样:

image.png

用户调用free(ptr)时,库会通过简单的指针运算得到头块的位置。获得头块的指针后,库可以很容易地确定幻数是否符合预期的值,作为正常性检查(assert(hptr->magic == 1234567)),并简单计算要释放的空间大小(即头块的大小加区域长度)。因此,如果用户请求N字节的内存,库不是寻找大小为N的空闲块,而是寻找N加上头块大小的空闲块。

让堆增长

大多数传统的分配程序会从很小的堆开始,当空间耗尽时,再向操作系统申请更大的空间。通常,这意味着它们进行了某种系统调用(例如,大多数UNIX系统中的sbrk),让堆增长。操作系统在执行sbrk系统调用时,会找到空闲的物理内存页,将它们映射到请求进程的地址空间中去,并返回新的堆的末尾地址。这时,就有了更大的堆,请求就可以成功满足。

基本策略

理想的分配程序可以同时保证快速和碎片最小化。遗憾的是,由于分配及释放的请求序列是任意的,任何策略在某些特定的输入下都会变得非常差。

最优匹配

最优匹配(best fit)策略非常简单:首先遍历整个空闲列表,找到和请求大小一样或更大的空闲块,然后返回这组候选者中最小的一块。最优匹配背后的想法很简单:选择最接近用户请求大小的块,从而尽量避免空间浪费。然而,简单的实现在遍历查找正确的空闲块时,要付出较高的性能代价。

最差匹配

最差匹配(worst fit)方法与最优匹配相反,它尝试找最大的空闲块,分割并满足用户需求后,将剩余的块加入空闲列表。最差匹配尝试在空闲列表中保留较大的块,而不是像最优匹配那样可能剩下很多难以利用的小块。最差匹配同样需要遍历整个空闲列表,大多数研究表明它的表现非常差,导致过量的碎片,同时还有很高的开销。

首次匹配

首次匹配(first fit)策略就是找到第一个足够大的块,将请求的空间返回给用户。首次匹配有速度优势(不需要遍历所有空闲块),但有时会让空闲列表开头的部分有很多小块。因此,分配程序如何管理空闲列表的顺序就变得很重要。一种方式是基于地址排序(address-basedordering),通过保持空闲块按内存地址有序,合并操作会很容易,从而减少了内存碎片。

下次匹配

不同于首次匹配每次都从列表的开始查找,下次匹配(next fit)算法多维护一个指针,指向上一次查找结束的位置。其想法是将对空闲空间的查找操作扩散到整个列表中去,避免对列表开头频繁的分割。这种策略的性能与首次匹配很接近,同样避免了遍历查找。

其他方式

除了上述基本策略外,人们还提出了许多技术和算法,来改进内存分配。

分离空闲列表

它的基本想法很简单:如果某个应用程序经常申请一种(或几种)大小的内存空间,那就用一个独立的列表,只管理这样大小的对象。其他大小的请求都交给更通用的内存分配程序。

这种方法的好处显而易见。通过拿出一部分内存专门满足某种大小的请求,碎片就不再是问题了。而且,由于没有复杂的列表查找过程,这种特定大小的内存分配和释放都很快。

不过这种方式也为系统引入了新的复杂性。例如,应该拿出多少内存来专门为某种大小的请求服务,而将剩余的用来满足一般请求?Solaris系统内核设计的厚块分配程序(slab allocator),很优雅地处理了这个问题。

具体来说,在内核启动时,它为可能频繁请求的内核对象创建一些对象缓存(object cache),如锁和文件系统inode等。这些的对象缓存每个分离了特定大小的空闲列表,因此能够很快地响应内存请求和释放。如果某个缓存中的空闲空间快耗尽时,它就向通用内存分配程序申请一些内存厚块(slab)(总量是页大小和对象大小的公倍数)。相反,如果给定厚块中对象的引用计数变为0,通用的内存分配程序可以从专门的分配程序中回收这些空间,这通常发生在虚拟内存系统需要更多的空间的时候。

厚块分配程序比大多数分离空闲列表做得更多,它将列表中的空闲对象保持在预初始化的状态。数据结构的初始化和销毁的开销很大,通过将空闲对象保持在初始化状态,厚块分配程序避免了频繁的初始化和销毁,从而显著降低了开销。

伙伴系统

因为合并对分配程序很关键,所以人们设计了一些方法,让合并变得简单,一个好例子就是二分伙伴分配程序(binary buddy allocator)。

在这种系统中,空闲空间首先从概念上被看成大小为2ⁿ的大空间。当有一个内存分配请求时,空闲空间被递归地一分为二,直到刚好可以满足请求的大小。这时,请求的块被返回给用户。在下面的例子中,一个64KB大小的空闲空间被切分,以便提供7KB的块:

image.png

请注意,这种分配策略只允许分配2的整数次幂大小的空闲块,因此会有内部碎片(internal fragment)的麻烦。

伙伴系统的精髓在于内存被释放的时候。如果将这个8KB的块归还给空闲列表,分配程序会检查“伙伴”8KB是否空闲。如果是,就合二为一,变成16KB的块。然后会检查这个16KB块的伙伴是否空闲,如果是,就合并这两块。这个递归合并过程继续上溯,直到合并整个内存区域,或者某一个块的伙伴还没有被释放。

伙伴系统运转良好的原因,在于很容易确定某个块的伙伴。仔细观察的话,就会发现每对互为伙伴的块只有一位不同,正是这一位决定了它们在整个伙伴树中的层次

其他想法

上面提到的众多方法都有一个重要的问题,缺乏可扩展性(scaling)。具体来说,就是查找列表可能很慢。因此,更先进的分配程序采用更复杂的数据结构来优化这个开销,牺牲简单性来换取性能。例子包括平衡二叉树、伸展树和偏序树。

考虑到现代操作系统通常会有多核,同时会运行多线程的程序,因此人们做了许多工作,提升分配程序在多核系统上的表现。感兴趣的话可以深入阅读glibc分配程序的工作原理。

阅读 838

IT民工,主要从事web方向,喜欢研究技术和投资之道

94 声望
598 粉丝
0 条评论
你知道吗?

IT民工,主要从事web方向,喜欢研究技术和投资之道

94 声望
598 粉丝
宣传栏