一般常用的page大小是4/8KB,那么一个32位的操作系统，将有1M长度的的分页表，单个表项按4字节计，page table为4MB，而每个进程都需要自己的page table,那么100个进程需要400MB内存，无疑是不小的空间开销，需要想办法压缩。

增大page

这无疑是简洁有效的，增大page会减小page table规模，但是负面效果也是明显的，大的page会导致内存利用率下降internal fragment。

许多系统支持多page size，但是多page size并不是为了减小page table而是为了减轻TLB压力。因为有些程序可以聪明地一次申请足够大的page, 将常用的数据结构放置于同一page下，从而提高内存存取效率。

混合paging & segments

当进程的堆和栈的使用率很低时，占用的内存可能是一个稀疏地址空间。也就是说绝大部分的page对进程都是invalid。此时与其保存所有page，不妨保存进程各数据段实际使用的page。

混合之后每个进程使用多个（如code, stack, heap）page table，同时MMU中的base寄存器存放值改为对应segment的page table基址，而bound则指标page的末端。

如果没有page，光segment是不好用的，因为heap要增长，你必须为Heap预留足够的空间，而有了page之后，VA与PA不再是线性对应的，page完全可以交错而对应的VA却是连续地址，因此二者的组合才能提供最大的虚拟化能力。

Multi-level Page Tables

多级page table用来解决page table体积过大的问题。它的解决思路也很简单：将page table切割成page size大小的单元，如果一个单元内的page table项都是invalid(未使用）,那么就不存储它（不使用内存空间）。同时使用一个page directory的结构来保存有数据的page table段的PFN信息。

一般来说进程不可能使用整个内存空间而是其很小一部分，所以这将大大地减小page table的体积。

但是这也同意意味着在page table之外又加了一层对应关系，如果TLB miss使用page table寻址时会造成额外的开销。

Inverted Page Tables

反向的意思是，对应关系反过来：不再每进程一个page table，而是保存每个page被进程使用的情况。寻找空闲空间的过程就变成了遍历table的过程，因而一般使用了hash表的形式。

小结

看到这里，基本已经理解了OS对内存管理的基本原理，虽然还没有涉及到swap等内容，但实现原理已经基本能够猜到。另外有了这些知识我们也更能理解为何说进程是基本管理单位，进程间为何不能直接通信，而线程与进程的最大差别等内容。