-
Notifications
You must be signed in to change notification settings - Fork 231
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
25 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
diff --git a/source/chapter4/3sv39-implementation-1.rst b/source/chapter4/3sv39-implementation-1.rst | ||
index 8275f627..cf698c0f 100644 | ||
--- a/source/chapter4/3sv39-implementation-1.rst | ||
+++ b/source/chapter4/3sv39-implementation-1.rst | ||
@@ -269,13 +269,13 @@ SV39 多级页表的硬件机制 | ||
多级页表 | ||
------------------------------- | ||
|
||
-页表的一种最简单的实现是线性表,也就是按照地址从低到高、输入的虚拟页号从 :math:`0` 开始递增的顺序依次在内存中(我们之前提到过页表的容量过大无法保存在 CPU 中)放置每个虚拟页号对应的页表项。由于每个页表项的大小是 :math:`8` 字节,我们只要知道第一个页表项(对应虚拟页号 :math:`0` )被放在的物理地址 :math:`\text{base_addr}` ,就能直接计算出每个输入的虚拟页号对应的页表项所在的位置。如下图所示: | ||
+页表的一种最简单的实现是线性表,也就是按照地址从低到高、输入的虚拟页号从 :math:`0` 开始递增的顺序依次在内存中(我们之前提到过页表的容量过大无法保存在 CPU 中)放置每个虚拟页号对应的页表项。由于每个页表项的大小是 :math:`8` 字节,我们只要知道第一个页表项(对应虚拟页号 :math:`0` )被放在的物理地址 :math:`\text{base\_addr}` ,就能直接计算出每个输入的虚拟页号对应的页表项所在的位置。如下图所示: | ||
|
||
.. image:: linear-table.png | ||
:height: 400 | ||
:align: center | ||
|
||
-事实上,对于虚拟页号 :math:`i` ,如果页表(每个应用都有一个页表,这里指其中某一个)的起始地址为 :math:`\text{base_addr}` ,则这个虚拟页号对应的页表项可以在物理地址 :math:`\text{base_addr}+8i` 处找到。这使得 MMU 的实现和内核的软件控制都变得非常简单。然而遗憾的是,这远远超出了我们的物理内存限制。由于虚拟页号有 :math:`2^{27}` 种,每个虚拟页号对应一个 :math:`8` 字节的页表项,则每个页表都需要消耗掉 :math:`1\text{GiB}` 内存!应用的数据还需要保存在内存的其他位置,这就使得每个应用要吃掉 :math:`1\text{GiB}` 以上的内存。作为对比,我们的 K210 开发板目前只有 :math:`8\text{MiB}` 的内存,因此从空间占用角度来说,这种线性表实现是完全不可行的。 | ||
+事实上,对于虚拟页号 :math:`i` ,如果页表(每个应用都有一个页表,这里指其中某一个)的起始地址为 :math:`\text{base\_addr}` ,则这个虚拟页号对应的页表项可以在物理地址 :math:`\text{base\_addr}+8i` 处找到。这使得 MMU 的实现和内核的软件控制都变得非常简单。然而遗憾的是,这远远超出了我们的物理内存限制。由于虚拟页号有 :math:`2^{27}` 种,每个虚拟页号对应一个 :math:`8` 字节的页表项,则每个页表都需要消耗掉 :math:`1\text{GiB}` 内存!应用的数据还需要保存在内存的其他位置,这就使得每个应用要吃掉 :math:`1\text{GiB}` 以上的内存。作为对比,我们的 K210 开发板目前只有 :math:`8\text{MiB}` 的内存,因此从空间占用角度来说,这种线性表实现是完全不可行的。 | ||
|
||
线性表的问题在于:它保存了所有虚拟页号对应的页表项,但是高达 :math:`512\text{GiB}` 的地址空间中真正会被应用使用到的只是其中极小的一个子集(本教程中的应用内存使用量约在数十~数百 :math:`\text{KiB}` 量级),也就导致有意义并能在页表中查到实际的物理页号的虚拟页号在 :math:`2^{27}` 中也只是很小的一部分。由此线性表的绝大部分空间其实都是被浪费掉的。 | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters