理论+实例，带你掌握Linux的页目录和页表

逃离我推掉我的手 2022-09-15 15:48 134阅读 0赞

> **摘要：**操作系统在加载用户程序的时候，不仅仅需要分配物理内存，来存放程序的内容；而且还需要分配物理内存，用来保存程序的页目录和页表。

本文分享自华为云社区《[Linux从头学15：【页目录和页表】-理论 + 实例 + 图文的最完全、最接地气详解][Linux_15_-_ _ _ _]》，作者： 道哥 。

在`x86`系统中，为了能够更加充分、灵活的使用物理内存，把物理内存按照`4KB`的单位进行分页。

然后通过中间的映射表，把连续的虚拟内存空间，映射到离散的物理内存空间。映射表中的每一个表项，都指向一个物理页的开始地址。

但是这样的映射表有一个明显的缺点：映射表自身也是需保存在物理内存中的。

在 32 位系统中，它使用了多达`4MB`的物理内存空间(每个表项`4`个字节，一共有`4G/4K`个表项)。

为了解决这个问题，`x86`处理器使用了两级转换：页目录和页表。

这篇文章，我们就从最基础的底层计算过程入手，把这个最重要的内存管理机制搞定，以后再学习更深入的知识点时，就会更容易理解了。

## 1. 页表的拆分过程 ##

在一个`32`位的系统中，物理内存的最大可表示空间就是`0xFFFF_FFFF`，也就是`4GB`。

虽然实际安装的物理内存可能远远没有这么大，但是在设计内存管理机制的时候，还是需要按照最大的可寻址范围来进行设计的。

按照一个物理页`4KB`的单位来划分，`4GB`空间可以分割为`1024 * 1024`个物理页:

![677b5d80a25c649f5718f8bc2da9b14d.png][]

在上一篇文章中，使用单一的映射表来指向这些物理页，导致了映射表自身占据了太多的物理内存空间。

一个用户程序中定义的几个段，可能实际上只使用了很小的空间，完全用不到 4 GB。

但是仍然需要为它分配多达 4GB 的物理内存空间来保存这个映射表，很浪费。

为了解决这个问题，可以把这个单一映射表拆分成`1024`个体积更小的映射表：

1. 每一个映射表中，只有 1024 个表项，每一个表项仍然指向一个物理页的起始地址;

2. 一共使用 1024 个这样的映射表;

![6eca9c46ad1077e183760ea71da49483.png][]

这样一来，1024(每个表中的表项个数) \* 1024(表的个数)，仍然可以覆盖`4GB`的物理内存空间。

这里的每一个表，就称作页表，所以一共有`1024`个页表。

一个页表中一共有`1024`个表项，每一个页表项占用`4`个字节，所以一个页表就占用`4KB`的物理内存空间，正好是一个物理页的大小。

也许有的小伙伴就开始算账了：一个页表自身占用`4KB`，那么`1024`个页表一共就占用了`4MB`的物理内存空间，仍然是很多啊？

是的，从总数上看是这样，但是：一个应用程序是不可能完全使用全部的 4GB 空间的，也许只要几十个页表就可以了。

例如：一个用户程序的代码段、数据段、栈段，一共就需要`10 MB`的空间，那么使用`3`个页表就足够了，加上页目录，一共需要`16 KB`的空间。

计算过程：

每一个页表项指向一个 4KB 的物理页，那么一个页表中 1024 个页表项，一共能覆盖 4MB 的物理内存;

那么 10MB 的程序，向上对齐取整之后(4MB 的倍数，就是 12 MB)，就需要 3 个页表就可以了。

![fc24d82caa20aed7a690a8be97bfce4e.png][]

记住上图中的一句话：一个页表，可以覆盖 4MB 的物理内存空间(1024 \* 4 KB)。

页表中，每一个表项的格式如下：

![a6ed81aa0e82410de1b89c4d0f5ded56.png][]

注意下面的这几个属性：

P(Present): 存在位。1 - 物理页存在; 0 - 物理页不存在;

RW(Read/Write): 读/写位。1 - 这个物理页可读可写; 0 - 这个物理页只可读;

D(Dirty): 脏位。表示这个物理页中的数据是否被写过;

## 2. 页目录结构 ##

现在，每一个物理页，都被一个页表中的一个表项来指向了，那么这`1024`个页表的地址，应该怎么来管理呢？

答案是：页目录表！

顾名思义：在页目录中，每一个表项指向一个页表的开始地址(物理地址)。

操作系统在加载用户程序的时候，不仅仅需要分配物理内存，来存放程序的内容;

而且还需要分配物理内存，用来保存程序的页目录和页表。

![c31c6b3ec25e87d94c5cc295b298f478.png][]

再来算算账：

刚才说过：每一个页表覆盖`4MB`的内存空间，那么页目录中一共有`1024`个表项，指向`1024`个页表的物理地址。

那么页目录能覆盖的内存空间就是`1024 * 4MB`，也就是`4GB`，正好是`32`位地址的最大寻址范围。

页目录中，每一个表项的格式如下：

![34fa4e28a39b0cbe317a0eeff930e52f.png][]

其中的属性字段，与页表中的属性类似，只不过它的描述对象是页表。

还有一点：每一个用户程序都有自己的页目录和页表！下文有详细说明。

## 3. 几个相关的寄存器 ##

现在，所有页表的物理地址被页目录表项指向了，那么页目录的物理地址，处理器是怎么知道的呢？

答案就是：`CR3 寄存器`，也叫做: `PDBR(Page Table Base Register)`。

这个寄存器中，保存了当前正在执行的那个任务的页目录地址。

每个任务(程序)都有自己的页目录和页表，页目录表的地址被记录在任务的`TSS`段中。

当操作系统调度任务的时候，处理器就会找到即将执行的新任务的 `TSS`段信息，然后把新任务的页目录开始地址更新到`CR3`寄存器中。

当新任务的指令开始被执行时，处理器在获取指令、操作数据时，操作的是线性地址。

页处理单元就会从`CR3` 寄存器中保存的页目录表开始，把这个线性地址最终转换成物理地址。

当然，处理器中还有一个快表，用来加快从线性地址到物理地址的转换过程。

`CR3`寄存器的格式如下：

![67a427894b1ad252cfb004201a1f1992.png][]

顺便把官网上的其他几个控制寄存器都贴出来：

![1c756f23e97a7a853fbf58f74aa4f43f.png][]

其中，`CR0`寄存器的最高位`PG`，就是开启页处理单元的开关。

也即是说：

当系统上电之后，刚开始的地址寻址方式一直是 \[段:偏移地址\] 的方式。

当启动代码准备好页目录和页表之后，就可以设置 CR0.PG = 1。

此时，处理器中的页处理单元就开始工作了：面对任何一个线性地址，都要经过页处理单元之后，才得到一个物理地址。

## 4. 加载用户程序时: 页目录、页表的分配和填充过程 ##

在之前的文章中，介绍过一个用户程序被操作系统加载的全过程，简述如下：

1. 读取程序 header 信息，解析出程序的总长度，从任务自己的虚拟内存中分配一块足够的连续空间;

2. 分配一个空闲物理页，用作程序的页目录，页目录的地址会记录在稍后创建的 TSS 段中;

3. 使用虚拟内存中的线性地址，分配一个物理页(4 KB)，登记到页目录和页表中;

4. 从硬盘上读取 8 个扇区的数据(每个扇区 512 字节)，存放到刚才分配的物理页中;

5. 检查程序内容是否读取完毕：是-进入第 6 步；否-返回到第 3 步;

6. 为用户程序创建一些必要的内核数据结构，比如：TSS、TCB/PCB 等等;

7. 为用户程序创建 LDT，并且在其中创建每一个段描述符;

8. 把操作系统的页目录中高端地址部分的表项，复制给用户程序的页目录表。

这样的话，所有用户程序的页目录中，高端地址的表项都指向相同的页表地址，就达到了共享“操作系统空间”的目的。

这里主要聊一下第`3`步，假设用户程序文件在硬盘上的长度是`20 MB`，电脑中实际安装的物理内存是`1 GB`。

可以先计算一下：页目录中，每一个表项覆盖的空间是 4 MB，那么 20 MB的数据，需要 5 个表项就可以了。

在初始状态，页目录中的所有表项都是空的，其中的`P`位都是为`0`，表示页表不存在。

操作系统首先从虚拟内存中，分配一块`20 MB`的空间，假设从`1 GB（0x4000_0000）`的地址处开始吧，这个地址是线性地址。

也就是说把应用程序的文件读取到内存中，从地址`0x4000_0000`开始存放，向高地址方向增长。

注意：在“平坦”型分段模型下，线性地址等于虚拟地址。

`0x4000_0000 = 0100_0000_0000_0000___0000_0000_0000_0000`

前`10`位表示该线性地址在页目录中的索引，中间`10`位表示页表中的索引，最后`12`位表示物理页中的偏移地址。

因此，前`10`位就是 `0100_0000_00`，表示这个线性地址位于页目录中的第`256`个表项：

![4fb7087ee5eecb9ec9df27c6ea137cad.png][]

操作系统发现这个表项中为空，没有指向任何一个页表。

于是就从物理内存中，找一个空闲的物理页，用作页目录中第`256`个表项指向的页表。

注意：这个物理页是用作页表，而不是用作存储用户程序文件。

假设在物理内存上`128 MB (0x0800_0000)`的地址处，找到一个空闲的物理页，用作这个页表。

![dbc5e710bd2443327be3ea5176801787.png][]

把页表中的`1024`个表项全部清空，并且把页表的物理地址`0x0800_0000`，登记在页目录中的第`256`个表项中：`0x08000`（上图黄色部分）。

为什么不是 `0x0800_0000`？

因为一个物理页的地址一定是`4KB`对齐的(最后的`12`位全部为`0`)，所以页目录的表项中只需要记录页表地址的高 20 位即可。

现在，页表也有了，下面就是分配一个物理页来存储程序的内容。

假设在刚才那个物理页(用作页表的那个)的上面，又找到一个空闲的物理页，地址是：`0x0800_1000`。

此时，这个用于存放程序内容的物理页的地址，就需要记录在页表的一个表项中了。

那么应该记录在页表中的什么位置呢？也就是应该登记在哪一个表项中呢？

需要根据线性地址的中间 10 位来确定：

`0x4000_0000 = 0100_0000_0000_0000___0000_0000_0000_0000`

中间`10`位的全部是`0`，说明索引值就是`0`，也就是说页表中的第`0`个表项，保存这个物理页的地址，如下图所示：

![30ef20561439fe954e8075961ca0b643.png][]

一个物理页的地址一定是`4KB`对齐的(最后的`12`位全部为`0`)，所以只需要记录物理页地址的高 20 位即可。

用于存储程序文件内容的物理页分配好了，下面就开始从硬盘中读取程序文件的内容了。

一个物理页的大小是`4 KB`，硬盘上一个扇区的大小是`512 B`，那么从硬盘上连续读取`8`个扇区的数据就可以把一个物理页写满。

刚才已经假设：用户程序文件在硬盘上的长度是`20 MB`。

当读取了一个物理页的内容后，通过计算发现用户程序内容还没有读取完，于是继续重复以上流程。

1. 线性地址增加 4KB：0x4000\_1000 = 0100\_0000\_0000\_0000\_\_\_0001\_0000\_0000\_0000;

2. 前 10 位没有变，仍然是页目录中的第 256 个表项，发现这个表项指向的页表已经存在了，于是就不用再分配物理页用作页表了;

3. 分配一个空闲物理页，用于存放程序内容，假设在 0x0100\_4000处找到一个，把这个地址登记在页表中;

此时，线性地址的中间 10 位的索引值是 1，所以登记在页表中的第 1 个表项。

4. 从硬盘上读取 8 个扇区的数据，写入这个物理页;

![0906e3141ce972810cbd6e2d7dd7313d.png][]

因为页目录中一个表项所覆盖的范围是`4 MB`(也就是一个页表中`1024`个表项所指向的物理页空间的总和)。

所以当读取了`4 MB`的程序内容之后，这个页表中的所有表项就被填满了。

此时，读取的程序内容所占用的【线性地址】空间是：`0x4000_0000 ~ 0x403F_FFFF`。

下面再继续读取新内容时，就从 `0x4040_0000` 这个线性地址处开始存放，读取过程与上面都是一样的：

1. 确定页目录表项：

0x4040\_0000 = 0100\_0000\_0100\_0000\_\_\_0000\_0000\_0000\_0000，前 10 位的索引值是 257;

2. 发现 257 这个表项为空，于是分配一个空闲的物理页，用作页表;

3. 分配一个物理页，用作存储程序文件的内容，并把这个物理页的地址记录在页表中;

线性地址 0x4040\_0000 的中间 10 位的索引值是 0，所以登记在页表的第一个表项中;

后面的过程就不再唠叨了，一样一样的~~

最终的页目录和页表的布局，类似下面这张图：

![dde73cd590d8f8db512bfb317891a437.png][]

## 5. 线性地址到物理地址的查找、计算实例 ##

如果理解了上一个主题的内容，那么部分应该就可以不用再看了，因为它俩是相反的过程，而且查找过程更简单一些。

仍然继续我们的假设：

1. 用户程序的长度是 20 MB，存放在虚拟内存 0x4000\_0000 ~ 0x4140\_0000 (线性地址)这段空间内;

2. 代码段的长度是 8 MB，从虚拟内存的 0x40C0\_0000 处开始存放;

也就是如下图所示：

![2dc00234e9c6b5eaef18d56b757aabf9.png][]

现在，用户程序的内容已经全部读取到内存中了，页目录、页表全部都安排妥当了。

在页目录表中，一共有 5 个表项，正好表示这`20MB`的地址空间。

其中，8 MB 的代码所存储的物理页地址，登记在页目录表中的 259 和 260 这两个表项中(上图右侧的绿色表项)。

目标：处理器在执行代码时，遇到一个线性地址`0x4100_8800`，页处理单元需要把它转换得到物理地址。

![7be3cc7728e349e011a699a0f2595904.png][]

`0x4100_8800 = 0100_0001_0000_0000___1000_1000_0000_0000`

首先，根据线性地址的前 10 位(`0100_0001_00`)，得到它在页目录中的索引值为`260`。

这个表项中记录的页表地址为 `0x08040`，因为页表地址的低`12`位一定是`bit0`，因此这个页表的地址就是`0x0804_0000`。

页目录表的开始地址，肯定是从 CR3 寄存器获取的;

然后，根据线性地址的中间 10 位(`00_0000___1000`)，得到页表中的索引值为`8`。

这个表项中记录的物理页地址为 `0x02004`，补上低位的`12`个`bit0`，就得到物理页的开始地址是`0x0200_4000`。

最后，根据线性地址的最后 12 位(`1000_0000_0000`)，得到它在物理页的偏移量 `2048`。

也就是说：从物理页的开始地址(`0x0200_4000`)，偏移`2048`个字节的地方，就是这个线性地址(`0x4100_8080`)对应的物理地址(`0x0200_4800`)。

大功告成！

**[点击关注，第一时间了解华为云新鲜技术~][Link 1]**

[Linux_15_-_ _ _ _]: https://link.zhihu.com/?target=https%3A//bbs.huaweicloud.com/blogs/303498%3Futm_source%3Dzhihu%26utm_medium%3Dbbs-ex%26utm_campaign%3Dother%26utm_content%3Dcontent
[677b5d80a25c649f5718f8bc2da9b14d.png]: /images/20220828/0b43a89934d2492fa55939884a9bf4eb.png
[6eca9c46ad1077e183760ea71da49483.png]: /images/20220828/6cb96c8195a04588b51a3aed22303d29.png
[fc24d82caa20aed7a690a8be97bfce4e.png]: /images/20220828/b2ca9a8ee4034883ae1fd7cc39746596.png
[a6ed81aa0e82410de1b89c4d0f5ded56.png]: /images/20220828/6e791a2c1485457eadecff0e45e366ea.png
[c31c6b3ec25e87d94c5cc295b298f478.png]: /images/20220828/919dc3eb24ce430cbc440b4ee6029157.png
[34fa4e28a39b0cbe317a0eeff930e52f.png]: /images/20220828/bb0225ccaa9c4cea9c761e02bce63547.png
[67a427894b1ad252cfb004201a1f1992.png]: /images/20220828/fb6fae03935c451e8867876ebbeb06a8.png
[1c756f23e97a7a853fbf58f74aa4f43f.png]: /images/20220828/d3d62d5a09f7401b8783095e8493894d.png
[4fb7087ee5eecb9ec9df27c6ea137cad.png]: /images/20220828/36a5a2f5b52849528350c000105dffa5.png
[dbc5e710bd2443327be3ea5176801787.png]: /images/20220828/59585f70f3284f0f9e0eef03eca997a8.png
[30ef20561439fe954e8075961ca0b643.png]: /images/20220828/52ff5d8e5203487185368f4cb6be5872.png
[0906e3141ce972810cbd6e2d7dd7313d.png]: /images/20220828/dada51b68f2049d2b15ce396494f7a2f.png
[dde73cd590d8f8db512bfb317891a437.png]: /images/20220828/504db11743aa48dd9e01654d42fdf00e.png
[2dc00234e9c6b5eaef18d56b757aabf9.png]: /images/20220828/ab6ba9a0ac324a03a1c95a27a2965a71.png
[7be3cc7728e349e011a699a0f2595904.png]: /images/20220828/b729c2599efa4487b9ed3995cba70af9.png
[Link 1]: https://link.zhihu.com/?target=https%3A//bbs.huaweicloud.com/blogs%3Futm_source%3Dzhihu%26utm_medium%3Dbbs-ex%26utm_campaign%3Dother%26utm_content%3Dcontent