简介

在本实验中，你将为你的操作系统写内存管理方面的代码。内存管理由两部分组成。

第一部分是内核的物理内存分配器，内核通过它来分配内存，以及在不需要时释放所分配的内存。分配器以 页 page 为单位分配内存，每个页的大小为 4096 字节。你的任务是去维护那个数据结构，它负责记录物理页的分配和释放，以及每个分配的页有多少进程共享它。本实验中你将要写出分配和释放内存页的全套代码。

第二个部分是虚拟内存的管理，它负责由内核和用户软件使用的虚拟内存地址到物理内存地址之间的映射。当使用内存时，x86 架构的硬件是由内存管理单元（MMU）负责执行映射操作来查阅一组页表。接下来你将要修改 JOS，以根据我们提供的特定指令去设置 MMU 的页表。

预备知识

在本实验及后面的实验中，你将逐步构建你的内核。我们将会为你提供一些附加的资源。使用 Git 去获取这些资源、提交自实验 1 以来的改变（如有需要的话）、获取课程仓库的最新版本、以及在我们的实验 2 （origin/lab2）的基础上创建一个称为 lab2 的本地分支：

athena% cd ~/6.828/lab
athena% add git
athena% git pull
Already up-to-date.
athena% git checkout -b lab2 origin/lab2
Branch lab2 set up to track remote branch refs/remotes/origin/lab2.
Switched to a new branch "lab2"
athena%

上面的 git checkout -b 命令其实做了两件事情：首先它创建了一个本地分支 lab2，它跟踪给我们提供课程内容的远程分支 origin/lab2 ，第二件事情是，它改变你的 lab 目录的内容以反映 lab2 分支上存储的文件的变化。Git 允许你在已存在的两个分支之间使用 git checkout *branch-name* 命令去切换，但是在你切换到另一个分支之前，你应该去提交那个分支上你做的任何有意义的变更。

现在，你需要将你在 lab1 分支中的改变合并到 lab2 分支中，命令如下：

athena% git merge lab1
Merge made by recursive.
 kern/kdebug.c  |   11 +++++++++-- 
 kern/monitor.c |   19 +++++++++++++++++++
 lib/printfmt.c |    7 +++----
 3 files changed, 31 insertions(+), 6 deletions(-)
athena%

在一些案例中，Git 或许并不知道如何将你的更改与新的实验任务合并（例如，你在第二个实验任务中变更了一些代码的修改）。在那种情况下，你使用 git 命令去合并，它会告诉你哪个文件发生了冲突，你必须首先去解决冲突（通过编辑冲突的文件），然后使用 git commit -a 去重新提交文件。

实验 2 包含如下的新源代码，后面你将逐个了解它们：

• inc/memlayout.h
• kern/pmap.c
• kern/pmap.h
• kern/kclock.h
• kern/kclock.c

memlayout.h 描述虚拟地址空间的布局，这个虚拟地址空间是通过修改 pmap.c、memlayout.h 和 pmap.h 所定义的 PageInfo 数据结构来实现的，这个数据结构用于跟踪物理内存页面是否被释放。kclock.c 和 kclock.h 维护 PC 上基于电池的时钟和 CMOS RAM 硬件，在此，BIOS 中记录了 PC 上安装的物理内存数量，以及其它的一些信息。在 pmap.c 中的代码需要去读取这个设备硬件，以算出在这个设备上安装了多少物理内存，但这部分代码已经为你完成了：你不需要知道 CMOS 硬件工作原理的细节。

特别需要注意的是 memlayout.h 和 pmap.h，因为本实验需要你去使用和理解的大部分内容都包含在这两个文件中。你或许还需要去看看 inc/mmu.h 这个文件，因为它也包含了本实验中用到的许多定义。

开始本实验之前，记得去添加 exokernel 以获取 QEMU 的 6.828 版本。

实验过程

在你准备进行实验和写代码之前，先添加你的 answers-lab2.txt 文件到 Git 仓库，提交你的改变然后去运行 make handin。

athena% git add answers-lab2.txt
athena% git commit -am "my answer to lab2"
[lab2 a823de9] my answer to lab2 4 files changed, 87 insertions(+), 10 deletions(-)
athena% make handin

正如前面所说的，我们将使用一个评级程序来分级你的解决方案，你可以在 lab 目录下运行 make grade，使用评级程序来测试你的内核。为了完成你的实验，你可以改变任何你需要的内核源代码和头文件。但毫无疑问的是，你不能以任何形式去改变或破坏评级代码。

第 1 部分：物理页面管理

操作系统必须跟踪物理内存页是否使用的状态。JOS 以“页”为最小粒度来管理 PC 的物理内存，以便于它使用 MMU 去映射和保护每个已分配的内存片段。

现在，你将要写内存的物理页分配器的代码。它将使用 struct PageInfo 对象的链表来保持对物理页的状态跟踪，每个对象都对应到一个物理内存页。在你能够编写剩下的虚拟内存实现代码之前，你需要先编写物理内存页面分配器，因为你的页表管理代码将需要去分配物理内存来存储页表。

练习 1

在文件 kern/pmap.c 中，你需要去实现以下函数的代码（或许要按给定的顺序来实现）。

• boot_alloc()
• mem_init()（只要能够调用 check_page_free_list() 即可）
• page_init()
• page_alloc()
• page_free()

check_page_free_list() 和 check_page_alloc() 可以测试你的物理内存页分配器。你将需要引导 JOS 然后去看一下 check_page_alloc() 是否报告成功即可。如果没有报告成功，修复你的代码直到成功为止。你可以添加你自己的 assert() 以帮助你去验证是否符合你的预期。

本实验以及所有的 6.828 实验中，将要求你做一些检测工作，以便于你搞清楚它们是否按你的预期来工作。这个任务不需要详细描述你添加到 JOS 中的代码的细节。查找 JOS 源代码中你需要去修改的那部分的注释；这些注释中经常包含有技术规范和提示信息。你也可能需要去查阅 JOS 和 Intel 的技术手册、以及你的 6.004 或 6.033 课程笔记的相关部分。

第 2 部分：虚拟内存

在你开始动手之前，需要先熟悉 x86 内存管理架构的保护模式：即分段和页面转换。

练习 2

如果你对 x86 的保护模式还不熟悉，可以查看 Intel 80386 参考手册的第 5 章和第 6 章。阅读这些章节（5.2 和 6.4）中关于页面转换和基于页面的保护。我们建议你也去了解关于段的章节；在虚拟内存和保护模式中，JOS 使用了分页、段转换、以及在 x86 上不能禁用的基于段的保护，因此你需要去理解这些基础知识。

虚拟地址、线性地址和物理地址

在 x86 的专用术语中，一个 虚拟地址 virtual address 是由一个段选择器和在段中的偏移量组成。一个 线性地址 linear address 是在页面转换之前、段转换之后得到的一个地址。一个 物理地址 physical address 是段和页面转换之后得到的最终地址，它最终将进入你的物理内存中的硬件总线。

一个 C 指针是虚拟地址的“偏移量”部分。在 boot/boot.S 中我们安装了一个 全局描述符表 Global Descriptor Table （GDT），它通过设置所有的段基址为 0，并且限制为 0xffffffff 来有效地禁用段转换。因此“段选择器”并不会生效，而线性地址总是等于虚拟地址的偏移量。在实验 3 中，为了设置权限级别，我们将与段有更多的交互。但是对于内存转换，我们将在整个 JOS 实验中忽略段，只专注于页转换。

回顾实验 1 中的第 3 部分，我们安装了一个简单的页表，这样内核就可以在 0xf0100000 链接的地址上运行，尽管它实际上是加载在 0x00100000 处的 ROM BIOS 的物理内存上。这个页表仅映射了 4MB 的内存。在实验中，你将要为 JOS 去设置虚拟内存布局，我们将从虚拟地址 0xf0000000 处开始扩展它，以映射物理内存的前 256MB，并映射许多其它区域的虚拟内存。

练习 3

虽然 GDB 能够通过虚拟地址访问 QEMU 的内存，它经常用于在配置虚拟内存期间检查物理内存。在实验工具指南中复习 QEMU 的监视器命令，尤其是 xp 命令，它可以让你去检查物理内存。要访问 QEMU 监视器，可以在终端中按 Ctrl-a c（相同的绑定返回到串行控制台）。

使用 QEMU 监视器的 xp 命令和 GDB 的 x 命令去检查相应的物理内存和虚拟内存，以确保你看到的是相同的数据。

我们的打过补丁的 QEMU 版本提供一个非常有用的 info pg 命令：它可以展示当前页表的一个具体描述，包括所有已映射的内存范围、权限、以及标志。原本的 QEMU 也提供一个 info mem 命令用于去展示一个概要信息，这个信息包含了已映射的虚拟内存范围和使用了什么权限。

在 CPU 上运行的代码，一旦处于保护模式（这是在 boot/boot.S 中所做的第一件事情）中，是没有办法去直接使用一个线性地址或物理地址的。所有的内存引用都被解释为虚拟地址，然后由 MMU 来转换，这意味着在 C 语言中的指针都是虚拟地址。

例如在物理内存分配器中，JOS 内存经常需要在不反向引用的情况下，去维护作为地址的一个很难懂的值或一个整数。有时它们是虚拟地址，而有时是物理地址。为便于在代码中证明，JOS 源文件中将它们区分为两种：类型 uintptr_t 表示一个难懂的虚拟地址，而类型 physaddr_trepresents 表示物理地址。这些类型其实不过是 32 位整数（uint32_t）的同义词，因此编译器不会阻止你将一个类型的数据指派为另一个类型！因为它们都是整数（而不是指针）类型，如果你想去反向引用它们，编译器将报错。

JOS 内核能够通过将它转换为指针类型的方式来反向引用一个 uintptr_t 类型。相反，内核不能反向引用一个物理地址，因为这是由 MMU 来转换所有的内存引用。如果你转换一个 physaddr_t 为一个指针类型，并反向引用它，你或许能够加载和存储最终结果地址（硬件将它解释为一个虚拟地址），但你并不会取得你想要的内存位置。

总结如下：

问题：

1. 假设下面的 JOS 内核代码是正确的，那么变量 x 应该是什么类型？uintptr_t 还是 physaddr_t ？

JOS 内核有时需要去读取或修改它只知道其物理地址的内存。例如，添加一个映射到页表，可以要求分配物理内存去存储一个页目录，然后去初始化它们。然而，内核也和其它的软件一样，并不能跳过虚拟地址转换，内核并不能直接加载和存储物理地址。一个原因是 JOS 将重映射从虚拟地址 0xf0000000 处的物理地址 0 开始的所有的物理地址，以帮助内核去读取和写入它知道物理地址的内存。为转换一个物理地址为一个内核能够真正进行读写操作的虚拟地址，内核必须添加 0xf0000000 到物理地址以找到在重映射区域中相应的虚拟地址。你应该使用 KADDR(pa) 去做那个添加操作。

JOS 内核有时也需要能够通过给定的内核数据结构中存储的虚拟地址找到内存中的物理地址。内核全局变量和通过 boot_alloc() 分配的内存是在内核所加载的区域中，从 0xf0000000 处开始的这个所有物理内存映射的区域。因此，要转换这些区域中一个虚拟地址为物理地址时，内核能够只是简单地减去 0xf0000000 即可得到物理地址。你应该使用 PADDR(va) 去做那个减法操作。

引用计数

在以后的实验中，你将会经常遇到多个虚拟地址（或多个环境下的地址空间中）同时映射到相同的物理页面上。你将在 struct PageInfo 数据结构中的 pp_ref 字段来记录一个每个物理页面的引用计数器。如果一个物理页面的这个计数器为 0，表示这个页面已经被释放，因为它不再被使用了。一般情况下，这个计数器应该等于所有页表中物理页面出现在 UTOP 之下的次数（UTOP 之上的映射大都是在引导时由内核设置的，并且它从不会被释放，因此不需要引用计数器）。我们也使用它去跟踪放到页目录页的指针数量，反过来就是，页目录到页表页的引用数量。

使用 page_alloc 时要注意。它返回的页面引用计数总是为 0，因此，一旦对返回页做了一些操作（比如将它插入到页表），pp_ref 就应该增加。有时这需要通过其它函数（比如，page_instert）来处理，而有时这个函数是直接调用 page_alloc 来做的。

页表管理

现在，你将写一套管理页表的代码：去插入和删除线性地址到物理地址的映射表，并且在需要的时候去创建页表。

练习 4

在文件 kern/pmap.c 中，你必须去实现下列函数的代码。

• pgdir\_walk()
• bootmapregion()
• page\_lookup()
• page\_remove()
• page\_insert()

check_page()，调用自 mem_init()，测试你的页表管理函数。在进行下一步流程之前你应该确保它成功运行。

第 3 部分：内核地址空间

JOS 分割处理器的 32 位线性地址空间为两部分：用户环境（进程），（我们将在实验 3 中开始加载和运行），它将控制其上的布局和低位部分的内容；而内核总是维护对高位部分的完全控制。分割线的定义是在 inc/memlayout.h 中通过符号 ULIM 来划分的，它为内核保留了大约 256MB 的虚拟地址空间。这就解释了为什么我们要在实验 1 中给内核这样的一个高位链接地址的原因：如是不这样做的话，内核的虚拟地址空间将没有足够的空间去同时映射到下面的用户空间中。

你可以在 inc/memlayout.h 中找到一个图表，它有助于你去理解 JOS 内存布局，这在本实验和后面的实验中都会用到。

权限和故障隔离

由于内核和用户的内存都存在于它们各自环境的地址空间中，因此我们需要在 x86 的页表中使用权限位去允许用户代码只能访问用户所属地址空间的部分。否则，用户代码中的 bug 可能会覆写内核数据，导致系统崩溃或者发生各种莫名其妙的的故障；用户代码也可能会偷窥其它环境的私有数据。

对于 ULIM 以上部分的内存，用户环境没有任何权限，只有内核才可以读取和写入这部分内存。对于 [UTOP,ULIM] 地址范围，内核和用户都有相同的权限：它们可以读取但不能写入这个地址范围。这个地址范围是用于向用户环境暴露某些只读的内核数据结构。最后，低于 UTOP 的地址空间是为用户环境所使用的；用户环境将为访问这些内核设置权限。

初始化内核地址空间

现在，你将去配置 UTOP 以上的地址空间：内核部分的地址空间。inc/memlayout.h 中展示了你将要使用的布局。我将使用函数去写相关的线性地址到物理地址的映射配置。

练习 5

完成调用 check_page() 之后在 mem_init() 中缺失的代码。

现在，你的代码应该通过了 check_kern_pgdir() 和 check_page_installed_pgdir() 的检查。

问题：

​ 1、在这个时刻，页目录中的条目（行）是什么？它们映射的址址是什么？以及它们映射到哪里了？换句话说就是，尽可能多地填写这个表：

条目	虚拟地址基址	指向（逻辑上）：
1023	?	物理内存顶部 4MB 的页表
1022	?	?
.	?	?
.	?	?
.	?	?
2	0x00800000	?
1	0x00400000	?
0	0x00000000	[参见下一问题]

​ 2、(来自课程 3) 我们将内核和用户环境放在相同的地址空间中。为什么用户程序不能去读取和写入内核的内存？有什么特殊机制保护内核内存？

​ 3、这个操作系统能够支持的最大的物理内存数量是多少？为什么？

​ 4、如果我们真的拥有最大数量的物理内存，有多少空间的开销用于管理内存？这个开销可以减少吗？

​ 5、复习在 kern/entry.S 和 kern/entrypgdir.c 中的页表设置。一旦我们打开分页，EIP 仍是一个很小的数字（稍大于 1MB）。在什么情况下，我们转而去运行在 KERNBASE 之上的一个 EIP？当我们启用分页并开始在 KERNBASE 之上运行一个 EIP 时，是什么让我们能够一个很低的 EIP 上持续运行？为什么这种转变是必需的？

地址空间布局的其它选择

在 JOS 中我们使用的地址空间布局并不是我们唯一的选择。一个操作系统可以在低位的线性地址上映射内核，而为用户进程保留线性地址的高位部分。然而，x86 内核一般并不采用这种方法，因为 x86 向后兼容模式之一（被称为“虚拟 8086 模式”）“不可改变地”在处理器使用线性地址空间的最下面部分，所以，如果内核被映射到这里是根本无法使用的。

虽然很困难，但是设计这样的内核是有这种可能的，即：不为处理器自身保留任何固定的线性地址或虚拟地址空间，而有效地允许用户级进程不受限制地使用整个 4GB 的虚拟地址空间 —— 同时还要在这些进程之间充分保护内核以及不同的进程之间相互受保护！

将内核的内存分配系统进行概括类推，以支持二次幂为单位的各种页大小，从 4KB 到一些你选择的合理的最大值。你务必要有一些方法，将较大的分配单位按需分割为一些较小的单位，以及在需要时，将多个较小的分配单位合并为一个较大的分配单位。想一想在这样的一个系统中可能会出现些什么样的问题。

这个实验做完了。确保你通过了所有的等级测试，并记得在 answers-lab2.txt 中写下你对上述问题的答案。提交你的改变（包括添加 answers-lab2.txt 文件），并在 lab 目录下输入 make handin 去提交你的实验。

via: https://sipb.mit.edu/iap/6.828/lab/lab2/

作者：Mit 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

上一篇文章中我们学习了内核怎么为一个用户进程 管理虚拟内存，而没有提及文件和 I/O。这一篇文章我们将专门去讲这个重要的主题 —— 页面缓存。文件和内存之间的关系常常很不好去理解，而它们对系统性能的影响却是非常大的。

在面对文件时，有两个很重要的问题需要操作系统去解决。第一个是相对内存而言，慢的让人发狂的硬盘驱动器，尤其是磁盘寻道。第二个是需要将文件内容一次性地加载到物理内存中，以便程序间共享文件内容。如果你在 Windows 中使用 进程浏览器 去查看它的进程，你将会看到每个进程中加载了大约 ~15MB 的公共 DLL。我的 Windows 机器上现在大约运行着 100 个进程，因此，如果不共享的话，仅这些公共的 DLL 就要使用高达 ~1.5 GB 的物理内存。如果是那样的话，那就太糟糕了。同样的，几乎所有的 Linux 进程都需要 ld.so 和 libc，加上其它的公共库，它们占用的内存数量也不是一个小数目。

幸运的是，这两个问题都用一个办法解决了：页面缓存 —— 保存在内存中的页面大小的文件块。为了用图去说明页面缓存，我捏造出一个名为 render 的 Linux 程序，它打开了文件 scene.dat，并且一次读取 512 字节，并将文件内容存储到一个分配到堆中的块上。第一次读取的过程如下：

1. render 请求 scene.dat 从位移 0 开始的 512 字节。
2. 内核搜寻页面缓存中 scene.dat 的 4kb 块，以满足该请求。假设该数据没有缓存。
3. 内核分配页面帧，初始化 I/O 请求，将 scend.dat 从位移 0 开始的 4kb 复制到分配的页面帧。
4. 内核从页面缓存复制请求的 512 字节到用户缓冲区，系统调用 read() 结束。

读取完 12KB 的文件内容以后，render 程序的堆和相关的页面帧如下图所示：

它看起来很简单，其实这一过程做了很多的事情。首先，虽然这个程序使用了普通的读取（read）调用，但是，已经有三个 4KB 的页面帧将文件 scene.dat 的一部分内容保存在了页面缓存中。虽然有时让人觉得很惊奇，但是，普通的文件 I/O 就是这样通过页面缓存来进行的。在 x86 架构的 Linux 中，内核将文件认为是一系列的 4KB 大小的块。如果你从文件中读取单个字节，包含这个字节的整个 4KB 块将被从磁盘中读入到页面缓存中。这是可以理解的，因为磁盘通常是持续吞吐的，并且程序一般也不会从磁盘区域仅仅读取几个字节。页面缓存知道文件中的每个 4KB 块的位置，在上图中用 #0、#1 等等来描述。Windows 使用 256KB 大小的 视图 view ，类似于 Linux 的页面缓存中的 页面 page 。

不幸的是，在一个普通的文件读取中，内核必须拷贝页面缓存中的内容到用户缓冲区中，它不仅花费 CPU 时间和影响 CPU 缓存，在复制数据时也浪费物理内存。如前面的图示，scene.dat 的内存被存储了两次，并且，程序中的每个实例都用另外的时间去存储内容。我们虽然解决了从磁盘中读取文件缓慢的问题，但是在其它的方面带来了更痛苦的问题。内存映射文件是解决这种痛苦的一个方法：

当你使用文件映射时，内核直接在页面缓存上映射你的程序的虚拟页面。这样可以显著提升性能：Windows 系统编程 报告指出，在相关的普通文件读取上运行时性能提升多达 30% ，在 Unix 环境中的高级编程 的报告中，文件映射在 Linux 和 Solaris 也有类似的效果。这取决于你的应用程序类型的不同，通过使用文件映射，可以节约大量的物理内存。

对高性能的追求是永恒不变的目标，测量是很重要的事情，内存映射应该是程序员始终要使用的工具。这个 API 提供了非常好用的实现方式，它允许你在内存中按字节去访问一个文件，而不需要为了这种好处而牺牲代码可读性。在一个类 Unix 的系统中，可以使用 mmap 查看你的 地址空间，在 Windows 中，可以使用 CreateFileMapping.aspx)，或者在高级编程语言中还有更多的可用封装。当你映射一个文件内容时，它并不是一次性将全部内容都映射到内存中，而是通过 页面故障 来按需映射的。在 获取 需要的文件内容的页面帧后，页面故障句柄 映射你的虚拟页面 到页面缓存上。如果一开始文件内容没有缓存，这还将涉及到磁盘 I/O。

现在出现一个突发的状况，假设我们的 render 程序的最后一个实例退出了。在页面缓存中保存着 scene.dat 内容的页面要立刻释放掉吗？人们通常会如此考虑，但是，那样做并不是个好主意。你应该想到，我们经常在一个程序中创建一个文件，退出程序，然后，在第二个程序去使用这个文件。页面缓存正好可以处理这种情况。如果考虑更多的情况，内核为什么要清除页面缓存的内容？请记住，磁盘读取的速度要慢于内存 5 个数量级，因此，命中一个页面缓存是一件有非常大收益的事情。因此，只要有足够大的物理内存，缓存就应该保持全满。并且，这一原则适用于所有的进程。如果你现在运行 render 一周后， scene.dat 的内容还在缓存中，那么应该恭喜你！这就是什么内核缓存越来越大，直至达到最大限制的原因。它并不是因为操作系统设计的太“垃圾”而浪费你的内存，其实这是一个非常好的行为，因为，释放物理内存才是一种“浪费”。（LCTT 译注：释放物理内存会导致页面缓存被清除，下次运行程序需要的相关数据，需要再次从磁盘上进行读取，会“浪费” CPU 和 I/O 资源）最好的做法是尽可能多的使用缓存。

由于页面缓存架构的原因，当程序调用 write() 时，字节只是被简单地拷贝到页面缓存中，并将这个页面标记为“脏”页面。磁盘 I/O 通常并不会立即发生，因此，你的程序并不会被阻塞在等待磁盘写入上。副作用是，如果这时候发生了电脑死机，你的写入将不会完成，因此，对于至关重要的文件，像数据库事务日志，要求必须进行 fsync()（仍然还需要去担心磁盘控制器的缓存失败问题），另一方面，读取将被你的程序阻塞，直到数据可用为止。内核采取预加载的方式来缓解这个矛盾，它一般提前预读取几个页面并将它加载到页面缓存中，以备你后来的读取。在你计划进行一个顺序或者随机读取时（请查看 madvise()、readahead()、Windows 缓存提示.aspx#caching_behavior) ），你可以通过 提示 hint 帮助内核去调整这个预加载行为。Linux 会对内存映射的文件进行 预读取，但是我不确定 Windows 的行为。当然，在 Linux 中它可能会使用 O\_DIRECT 跳过预读取，或者，在 Windows 中使用 NO\_BUFFERING.aspx) 去跳过预读，一些数据库软件就经常这么做。

一个文件映射可以是私有的，也可以是共享的。当然，这只是针对内存中内容的更新而言：在一个私有的内存映射上，更新并不会提交到磁盘或者被其它进程可见，然而，共享的内存映射，则正好相反，它的任何更新都会提交到磁盘上，并且对其它的进程可见。内核使用 写时复制 copy on write （CoW）机制，这是通过 页面表条目 page table entry （PTE）来实现这种私有的映射。在下面的例子中，render 和另一个被称为 render3d 的程序都私有映射到 scene.dat 上。然后 render 去写入映射的文件的虚拟内存区域：

1. 两个程序私有地映射 scene.dat，内核误导它们并将它们映射到页面缓存，但是使该页面表条目只读。
2. render 试图写入到映射 scene.dat 的虚拟页面，处理器发生页面故障。
3. 内核分配页面帧，复制 scene.dat 的第二块内容到其中，并映射故障的页面到新的页面帧。
4. 继续执行。程序就当做什么都没发生。

上面展示的只读页面表条目并不意味着映射是只读的，它只是内核的一个用于共享物理内存的技巧，直到尽可能的最后一刻之前。你可以认为“私有”一词用的有点不太恰当，你只需要记住，这个“私有”仅用于更新的情况。这种设计的重要性在于，要想看到被映射的文件的变化，其它程序只能读取它的虚拟页面。一旦“写时复制”发生，从其它地方是看不到这种变化的。但是，内核并不能保证这种行为，因为它是在 x86 中实现的，从 API 的角度来看，这是有意义的。相比之下，一个共享的映射只是将它简单地映射到页面缓存上。更新会被所有的进程看到并被写入到磁盘上。最终，如果上面的映射是只读的，页面故障将触发一个内存段失败而不是写到一个副本。

动态加载库是通过文件映射融入到你的程序的地址空间中的。这没有什么可奇怪的，它通过普通的 API 为你提供与私有文件映射相同的效果。下面的示例展示了映射文件的 render 程序的两个实例运行的地址空间的一部分，以及物理内存，尝试将我们看到的许多概念综合到一起。

这是内存架构系列的第三部分的结论。我希望这个系列文章对你有帮助，对理解操作系统的这些主题提供一个很好的思维模型。

via:https://manybutfinite.com/post/page-cache-the-affair-between-memory-and-files/

作者：Gustavo Duarte 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

内存管理是操作系统的核心任务；它对程序员和系统管理员来说也是至关重要的。在接下来的几篇文章中，我将从实践出发着眼于内存管理，并深入到它的内部结构。虽然这些概念很通用，但示例大都来自于 32 位 x86 架构的 Linux 和 Windows 上。这第一篇文章描述了在内存中程序如何分布。

在一个多任务操作系统中的每个进程都运行在它自己的内存“沙箱”中。这个沙箱是一个 虚拟地址空间 virtual address space ，在 32 位的模式中它总共有 4GB 的内存地址块。这些虚拟地址是通过内核 页表 page table 映射到物理地址的，并且这些虚拟地址是由操作系统内核来维护，进而被进程所消费的。每个进程都有它自己的一组页表，但是这里有点玄机。一旦虚拟地址被启用，这些虚拟地址将被应用到这台电脑上的 所有软件，包括内核本身。因此，一部分虚拟地址空间必须保留给内核使用：

但是，这并不是说内核就使用了很多的物理内存，恰恰相反，它只使用了很少一部分可用的地址空间映射到其所需要的物理内存。内核空间在内核页表中被标记为独占使用于 特权代码 （ring 2 或更低），因此，如果一个用户模式的程序尝试去访问它，将触发一个页面故障错误。在 Linux 中，内核空间是始终存在的，并且在所有进程中都映射相同的物理内存。内核代码和数据总是可寻址的，准备随时去处理中断或者系统调用。相比之下，用户模式中的地址空间，在每次进程切换时都会发生变化：

蓝色的区域代表映射到物理地址的虚拟地址空间，白色的区域是尚未映射的部分。在上面的示例中，众所周知的内存“饕餮” Firefox 使用了大量的虚拟内存空间。在地址空间中不同的条带对应了不同的内存段，像 堆 heap 、 栈 stack 等等。请注意，这些段只是一系列内存地址的简化表示，它与 Intel 类型的段 并没有任何关系 。不过，这是一个在 Linux 进程的标准段布局：

当计算机还是快乐、安全的时代时，在机器中的几乎每个进程上，那些段的起始虚拟地址都是完全相同的。这将使远程挖掘安全漏洞变得容易。漏洞利用经常需要去引用绝对内存位置：比如在栈中的一个地址，一个库函数的地址，等等。远程攻击可以闭着眼睛选择这个地址，因为地址空间都是相同的。当攻击者们这样做的时候，人们就会受到伤害。因此，地址空间随机化开始流行起来。Linux 会通过在其起始地址上增加偏移量来随机化栈、内存映射段、以及堆。不幸的是，32 位的地址空间是非常拥挤的，为地址空间随机化留下的空间不多，因此 妨碍了地址空间随机化的效果。

在进程地址空间中最高的段是栈，在大多数编程语言中它存储本地变量和函数参数。调用一个方法或者函数将推送一个新的 栈帧 stack frame 到这个栈。当函数返回时这个栈帧被删除。这个简单的设计，可能是因为数据严格遵循 后进先出（LIFO） 的次序，这意味着跟踪栈内容时不需要复杂的数据结构 —— 一个指向栈顶的简单指针就可以做到。推入和弹出也因此而非常快且准确。也可能是，持续的栈区重用往往会在 CPU 缓存 中保持活跃的栈内存，这样可以加快访问速度。进程中的每个线程都有它自己的栈。

向栈中推送更多的而不是刚合适的数据可能会耗尽栈的映射区域。这将触发一个页面故障，在 Linux 中它是通过 expand_stack() 来处理的，它会去调用 acct_stack_growth() 来检查栈的增长是否正常。如果栈的大小低于 RLIMIT_STACK 的值（一般是 8MB 大小），那么这是一个正常的栈增长和程序的合理使用，否则可能是发生了未知问题。这是一个栈大小按需调节的常见机制。但是，栈的大小达到了上述限制，将会发生一个栈溢出，并且，程序将会收到一个 段故障 Segmentation Fault 错误。当映射的栈区为满足需要而扩展后，在栈缩小时，映射区域并不会收缩。就像美国联邦政府的预算一样，它只会扩张。

动态栈增长是 唯一例外的情况 ，当它去访问一个未映射的内存区域，如上图中白色部分，是允许的。除此之外的任何其它访问未映射的内存区域将触发一个页面故障，导致段故障。一些映射区域是只读的，因此，尝试去写入到这些区域也将触发一个段故障。

在栈的下面，有内存映射段。在这里，内核将文件内容直接映射到内存。任何应用程序都可以通过 Linux 的 mmap() 系统调用（ 代码实现）或者 Windows 的 CreateFileMapping().aspx) / MapViewOfFile().aspx) 来请求一个映射。内存映射是实现文件 I/O 的方便高效的方式。因此，它经常被用于加载动态库。有时候，也被用于去创建一个并不匹配任何文件的匿名内存映射，这种映射经常被用做程序数据的替代。在 Linux 中，如果你通过 malloc() 去请求一个大的内存块，C 库将会创建这样一个匿名映射而不是使用堆内存。这里所谓的“大”表示是超过了MMAP_THRESHOLD 设置的字节数，它的缺省值是 128 kB，可以通过 mallopt() 去调整这个设置值。

接下来讲的是“堆”，就在我们接下来的地址空间中，堆提供运行时内存分配，像栈一样，但又不同于栈的是，它分配的数据生存期要长于分配它的函数。大多数编程语言都为程序提供了堆管理支持。因此，满足内存需要是编程语言运行时和内核共同来做的事情。在 C 中，堆分配的接口是 malloc() 一族，然而在支持垃圾回收的编程语言中，像 C#，这个接口使用 new 关键字。

如果在堆中有足够的空间可以满足内存请求，它可以由编程语言运行时来处理内存分配请求，而无需内核参与。否则将通过 brk() 系统调用（代码实现）来扩大堆以满足内存请求所需的大小。堆管理是比较 复杂的，在面对我们程序的混乱分配模式时，它通过复杂的算法，努力在速度和内存使用效率之间取得一种平衡。服务一个堆请求所需要的时间可能是非常可观的。实时系统有一个 特定用途的分配器 去处理这个问题。堆也会出现 碎片化 ，如下图所示：

最后，我们抵达了内存的低位段：BSS、数据、以及程序文本。在 C 中，静态（全局）变量的内容都保存在 BSS 和数据中。它们之间的不同之处在于，BSS 保存 未初始化的 静态变量的内容，它的值在源代码中并没有被程序员设置。BSS 内存区域是 匿名 的：它没有映射到任何文件上。如果你在程序中写这样的语句 static int cntActiveUsers，cntActiveUsers 的内容就保存在 BSS 中。

反过来，数据段，用于保存在源代码中静态变量 初始化后 的内容。这个内存区域是 非匿名 的。它映射了程序的二进值镜像上的一部分，包含了在源代码中给定初始化值的静态变量内容。因此，如果你在程序中写这样的语句 static int cntWorkerBees = 10，那么，cntWorkerBees 的内容就保存在数据段中，并且初始值为 10。尽管可以通过数据段映射到一个文件，但是这是一个私有内存映射，意味着，如果改变内存，它并不会将这种变化反映到底层的文件上。必须是这样的，否则，分配的全局变量将会改变你磁盘上的二进制文件镜像，这种做法就太不可思议了！

用图去展示一个数据段是很困难的，因为它使用一个指针。在那种情况下，指针 gonzo 的内容（一个 4 字节的内存地址）保存在数据段上。然而，它并没有指向一个真实的字符串。而这个字符串存在于文本段中，文本段是只读的，它用于保存你的代码中的类似于字符串常量这样的内容。文本段也会在内存中映射你的二进制文件，但是，如果你的程序写入到这个区域，将会触发一个段故障错误。尽管在 C 中，它比不上从一开始就避免这种指针错误那么有效，但是，这种机制也有助于避免指针错误。这里有一个展示这些段和示例变量的图：

你可以通过读取 /proc/pid_of_process/maps 文件来检查 Linux 进程中的内存区域。请记住，一个段可以包含很多的区域。例如，每个内存映射的文件一般都在 mmap 段中的它自己的区域中，而动态库有类似于 BSS 和数据一样的额外的区域。下一篇文章中我们将详细说明“ 区域 area ”的真正含义是什么。此外，有时候人们所说的“ 数据段 data segment ”是指“ 数据 data + BSS + 堆”。

你可以使用 nm 和 objdump 命令去检查二进制镜像，去显示它们的符号、地址、段等等。最终，在 Linux 中上面描述的虚拟地址布局是一个“弹性的”布局，这就是这几年来的缺省情况。它假设 RLIMIT_STACK 有一个值。如果没有值的话，Linux 将恢复到如下所示的“经典” 布局：

这就是虚拟地址空间布局。接下来的文章将讨论内核如何对这些内存区域保持跟踪、内存映射、文件如何读取和写入、以及内存使用数据的意义。

via: http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/

作者：Gustavo Duarte 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出