Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
rcore-os
RCore Tutorial Book V3
提交
99ca7fe7
R
RCore Tutorial Book V3
项目概览
rcore-os
/
RCore Tutorial Book V3
9 个月 前同步成功
通知
3
Star
938
Fork
153
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
RCore Tutorial Book V3
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
99ca7fe7
编写于
4月 06, 2023
作者:
Y
Yifan Wu
1
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Add latexpdf patch
上级
41ff56d8
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
25 addition
and
5 deletion
+25
-5
scripts/latexpdf.patch
scripts/latexpdf.patch
+20
-0
source/setup-sphinx.rst
source/setup-sphinx.rst
+5
-5
未找到文件。
scripts/latexpdf.patch
0 → 100644
浏览文件 @
99ca7fe7
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}` 中也只是很小的一部分。由此线性表的绝大部分空间其实都是被浪费掉的。
source/setup-sphinx.rst
浏览文件 @
99ca7fe7
...
...
@@ -11,9 +11,9 @@
4. 修改之后,在项目根目录下 ``make clean && make html`` 即可在 ``build/html/index.html`` 查看本地构建的主页。请注意在修改章节目录结构或者更新各种配置文件/python 脚本之后需要 ``make clean`` 一下,不然可能无法正常更新。
5. 如想对项目做贡献的话,直接提交 pull request 即可。
补充:
支持实时显示修改rst文件后的html文档的方法:
.. note::
**实时显示修改rst文件后的html文档的方法**
1. ``pip install autoload`` 安装 Sphinx 自动加载插件。
2. 在项目根目录下 ``sphinx-autobuild source build/html`` 即可在浏览器中访问 `http://127.0.0.1:8000/` 查看本地构建的主页。
\ No newline at end of file
1. ``pip install autoload`` 安装 Sphinx 自动加载插件。
2. 在项目根目录下 ``sphinx-autobuild source build/html`` 即可在浏览器中访问 `http://127.0.0.1:8000/` 查看本地构建的主页。
Miykael_xxm
🚴
@xiongjiamu
mentioned in commit
b6636c3d
·
4月 07, 2023
mentioned in commit
b6636c3d
mentioned in commit b6636c3d90b79d12e3897f34938a48e3367bab8b
开关提交列表
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录