当页表中的页表项大部分都有效的时候，多级页表还能节省空间吗？ 第1页

是会浪费内存。

这个甚至不需要学习多少体系架构的知识，简单算一下就知道了。

已知一页是4K(2^12)，32位下，一个页表项（不开启PAE）是4字节（32位），那么页表项消耗的内存正好是实际消耗内存的1/1024（接近千分之一）的水平。千分之一已经很少了，如果开启了大页（2M页/1G页）那么消耗会更少，所以正常使用是无需担心这个问题的。

当然，有一种特殊的情形，是会造成页表项的浪费的：

以32位为例，一个Page table（页表）可以表达1024个页（实际可能是512个，因为主流OS都开启PAE，本文暂不讨论PAE），如果一个page table只映射了一个页，那么剩下的1023个表项就完全浪费了，所以，可以构造一个内存分布方式：从0地址开始，每4M地址分配一个4K页，那么page table就跟实际物理内存一样多了，加上二级表项就更多了。又因为页表项不连续，所以TLB miss的概率很高，所以题主的这种问题是肯定存在的。

但真的会有程序这么做吗？正常情况下不会。

实际运行的程序，使用虚地址（也就是开启分页）的主要目的是让数据和代码都是集中在某个内存区域内的，而不是因为内存碎片原因导致数据零散存放。举个例子：我要加载一个1MB的数据到内存，这1MB的数据肯定是连续存放的，不可能出现前面我说的，把1MB拆成256个4K页，然后分散到256*4M的内存区域里存放，真要这么放，写代码操作数据会非常麻烦，每访问4K，就要跳过4M的地址，估计做开发的人会疯了。

而代码段更不可能出现这种情况，代码段都是编译器生成，操作系统加载的，目前没有哪个编译器会发神经把一个完整的可执行程序，拆成一个一个4K的区域然后分散到4M地址上。

所以，除了人为构造这种页表结构以外，看不出实际应用中，会有人遇到这种问题。况且，硬件还提供大页的支持，嫌页表太多，用2M页/1G页就可以避免了。