i386的页式内存管理机制.docVIP

i386的页式内存管理机制 学过操作系统原理的读者都知道，内存管理有两种，一种是段式管理，另一种是页式管理，而页式管理更为先进。从80年代中期开始，页式内存管理进入了各种操作系统（以Unix为主）的内核，一时成为操作系统的一个热点。 Intel从80286开始实现其“保护模式”，也即段式内存管理。但是很快就发现，光有段式内存管理而没有页式内存管理是不够的，那样会使它的X86系列逐渐失去竞争力以及作为主流CPU产品的地位。因此，在不久以后的80386中就实现了对页式内存管理的支持。也就是说，80386除了完成并完善从80286开始的段式内存管理的同时还实现了页式内存管理。 前面讲过，80386的段式内存管理机制，是将指令中结合段寄存器使用的32位逻辑地址映射（转换成）同样是32位的物理地址。之所以称之为“物理地址”。是因为这是真正放到地址总线上去，并用以寻访物理上存在着的具体内存单元的地址。但是，段式存储管理机制的灵活性和效率都比较差。一方面“段”是可变长度的，这就给磁盘交换操作带来了不便；另一方面，如果为了增加灵活性而将一个进程的空间划分成很多小段时，就势必要求在程序中频繁地改变段寄存器的内容。同时，如果将段分小，虽然一个段描述表中可以容纳8192个描述项（因为有13位下标），也未必能保证足够使用。所以，比较好的办法还是采用页式存储管理。本来，页式存储并不需要建立在段式存储管理的基础上，这是两种不同的机制。可是，在80386中，保护模式的实现是与段式存储密不可分的。例如CPU的当前执行权限就是在有关的代码段描述项中规定的。读过Unix早期版本的读者不妨将此与PDP-11中的情况作一对比。在PDP-11中CPU的当前执行权限存放在一个独立的寄存器PSW中，而与任何其他的数据结构没有关系。因此，在80386中，既然决定利用部分已经存在的资源，而不是完全另起炉灶，那就无法绕过段式存储管理来实现页式存储管理。也就是说，80386的系统结构决定了它的页式存储管理只能建立在段式存储管理的基础上。这也意味着，页式存储管理的作用是在由段式存储管理所映射而成的地址上再加上一层地址映射。由于此时由段式存储管理映射而成的地址??再是“物理地址”了，Intel就称之为“线性地址”。于是，段式存储管理先将逻辑地址映射成线性地址，然后由页式存储管理将线性地址映射成物理地址；或者，当不使用页式存储管理时，就将线性地址直接用作物理地址。 80386把线性地址空间划分成4K字节的页面，每个页面可以被映射至物理存储空间中任意一块4K大小的区间（边界必须与4K字节对其）。在段式存储管理中，连续的逻辑地址经过映射后在线性地址空间中还是连续的。但是在页式存储管理中，连续的线性地址空间经过映射后在物理空间却不一定连续（其灵活性也正在于此）。这里值得指出的是，虽然页式存储管理是建立在段式存储管理的基础上的，但一旦启用了页式存储管理，所有的线性地址都要经过页式映射，连GDTR和LDTR中给出的段描述表起始地址也不例外。 由于页式存储管理的引入，对32位的线性地址有了新的解释（以前就是物理地址）： typedef struct { Unsigned int dir:10; /* 用作页面表目录中的下标，该目录项指向一个页面表 */ unsigned int page:10; /* 用作具体页面表中的下标，该表项指向一个物理页面 */ unsigned int offset:12; /* 在4K字节物理页面内的偏移量 */ }线性地址; 这个结构可以用下图形象地表示。 可以看出，在页面目录中共有2^10＝1024个目录项，每个目录项指向一个页面表，而在每个页面表中又共有1024个页面描述项。类似于GDTR和LDTR，又增加了一个新的寄存器CR3作为指向当前页面目录的指针。这样，从线性地址到物理地址的映射过程为： 1. 从CR3取得页面目录的基地址。 2. 以线性地址中的dir位段为下标，在目录中取得相应页面表的基地址。 3. 以线性地址中的page位段为下标，在所得到的页面表中取得相应的页面描述项。将页面描述项中给出的页面基地址与线性地址中的offset位段相加得到物理地址。 上列映射过程可用下图直观地表示。 那么，为什么要使用两个层次，先找到目录项，再找到页面描述项，而不是像在使用段寄存器时那样一步到位呢？这是出于空间效率的考虑。如果将线性地址中的dir和page两个位段合并在一起是20位，因此页面表的大小就将是1K×1K＝1M个表项。由于每个页面的大小为4K字节，总的空间大小仍为4K×1M＝4G，正好是32位地址空间的大小。但是，实际上很难想象有一个进程会需要用到4G的全部空间，所以大部分表项势必是空着的。可是，在一个数组中，即使是空着不用的表项也占用空间