我们的指令和数据，都必须先加载到内存，才会被CPU拿去执行。但是程序并不能直接访问到物理内存。从这里可以知道，程序是怎么装载到内存中执行的。

我们的内存需要被分成固定大小的页（Page），然后才通过虚拟内存地址到物理内存地址的地址转换，才能到达实际存放数据的物理内存位置。而我们的程序看到的内存地址，都是虚拟内存地址。

那么，这些虚拟内存地址究竟是怎么转换成物理地址的呢？

内存保护的主要目的是防止某个进程去访问不是操作系统配置给它的寻址空间

想要把虚拟内存地址，映射到物理内存地址，最直观的方法，就是来键一张映射表。这个映射表，能够实现虚拟内存里面的页，到物理内存里面的页的一一映射。这会映射表，在计算机里面，就叫做页表（page table）

页表这个地址转换的办法，会把一个内存地址分成页号（Directory）和偏移量（Offset）两个部分。以一个32位的内存地址为例：

总结一下，对于一个内存地址转换，其实就是这样三个步骤：

看起来这个逻辑似乎很简单，很容易理解，不过问题马上就来了

仔细想一想，我们其实没有必要存下这 2^20 个物理页表啊。大部分进程所占用的内存是有限的，需要的页也自然是有限的，我们只需要去存那些用到的页之间的映射关系就好了。

也就引入了多级页表（Multi-Level Page Table）。那为什么不用哈希表呢？

（哈希表有哈希冲突，而且顺序乱，不符合局部性原理）

我们先来看一看，一个进程的内存地址空间是怎么分配的。在整个进程的内存地址空间，通常是“两头实，中间空”。在程序运行的时候，内存地址从顶部往下，不断分配占用的栈的空间。而堆的空间，内存地址则是从底部往上，是不断分配占用的。

所以，在一个实际的程序地址里面，虚拟内存占用的地址空间，通常是两端连续的空间。而不是完全随机的内存地址。而多级页表，就特别适合这样的内存地址分布。

我们以一个4级的多级页表为例，来看一下，同样一个虚拟内存地址，偏移量的部分和上面简单页表一样不变，但是原先的页号部分，我们把它拆成四段，从高到低，分成 4 级到1 级这样 4 个页表索引。

对应的，一个进程会有一个 4 级页表。我们先通过 4 级页表索引，找到 4 级页表里面对应的条目（Entry）。这个条目里存放的是一张 3 级页表所在的位置。4 级页面里面的每一个条目，都对应着一张 3 级页表，所以我们可能有多张 3 级页表。

找到对应这张 3 级页表之后，我们用 3 级索引去找到对应的 3 级索引的条目。3 级索引的条目再会指向一个 2 级页表。同样的，2 级页表里我们可以用 2 级索引指向一个 1 级页表。

而最后一层的 1 级页表里面的条目，对应的数据内容就是物理页号了。在拿到了物理页号之后，我们同样可以用“页号 + 偏移量”的方式，来获取最终的物理内存地址。

我们可能有很多张 1 级页表、2 级页表，乃至 3 级页表。但是，因为实际的虚拟内存空间通常是连续的，我们很可能只需要很少的 2 级页表，甚至只需要 1 张 3 级页表就够了

事实上，多级页表就像一个多叉树的数据结构，所以我们常常称它为页表树。因为虚拟内存地址分布的连续性，树的第一层节点的指针，很多就是空的，也就是不需要有对应的子树了。所谓不需要子树，其实就是不需要对应的 2 级、3 级的页表。找到最终的物理页号，就好像通过一个特定的访问路径，走到树最底层的叶子节点。

以这样的分成 4 级的多级页表来看，每一级如果都用 5 个比特表示。那么每一张某 1 级的页表，只需要 2^5=32 个条目。如果每个条目还是 4 个字节，那么一共需要 128 个字节。而一个 1 级索引表，对应 32 个 4KiB 的也就是 16KB 的大小。一个填满的 2 级索引表，对应的就是 32 个 1 级索引表，也就是 512KB 的大小。

我们可以一起来测算一下，一个进程如果占用了 1MB 的内存空间，分成了 2 个 512KB 的连续空间。那么，它一共需要 2 个独立的、填满的 2 级索引表，也就意味着 64 个 1 级索引表，2 个独立的 3 级索引表，1 个 4 级索引表。一共需要 69 个索引表，每个 128 字节，大概就是 9KB 的空间。比起 4MB 来说，只有差不多 1/500。

不过，多级页表虽然节约了我们的存储空间，却带来了时间上的开销，所以它其实是一个“时间换空间”的策略。原本我们进行一次地址转换，只需要访问一次就能找到物理内存地址。但是，用了4级页表，我们就需要访问4次内存，才能找到物理页号了。

问题是：内存访问其实比Cache要慢很多。我们本来只是要做一个简单的物理地址转换，现在却要多了访问多次内存。对于这个时间性能的损失，有什么好的办法吗？