【Linux系统】分页式存储管理

分页式存储管理

1、虚拟地址和页表的由来

思考一下，如果在没有虚拟内存和分页机制的情况下，每一个用户程序在物理内存上所对应的空间必须是连续的，如下图：

---

---

因为每一个程序的代码、数据长度都是不一样的，按照这样的映射方式，物理内存将会被分割成各种离散的、大小不同的块。经过一段运行时间之后，有些程序会退出，那么它们占据的物理内存空间可以被回收，导致这些物理内存都是以很多碎片的形式存在。

怎么办呢？我们希望操作系统提供给用户的空间必须是连续的，但是物理内存最好不要连续。 此时虚拟内存和分页便出现了，如下图所示：

---

---

把物理内存按照一个固定的长度的页框进行分割，有时叫做物理页。每个页框包含一个物理页 (page) 。一个页的大小等于页框的大小。大多数32位体系结构支持4KB的页，而64位体系结构一般会支持8KB的页。区分一页和一个页框是很重要的：

• 页框是一个存储区域；
• 页是一个数据块，可以存放在任何页框或磁盘中。
  
  

有了这种机制，CPU便并非是直接访问物理内存地址，而是通过虚拟地址空间来间接的访问物理内存地址。所谓的虚拟地址空间，是操作系统为每一个正在执行的进程分配的一个逻辑地址，在32位机上，其范围从0 ~ 4G-1。

操作系统通过将虚拟地址空间和物理内存地址之间建立映射关系，也就是页表，这张表上记录了每一对页和页框的映射关系，能让CPU间接的访问物理内存地址。

总结一下，其思想是将虚拟内存下的逻辑地址空间分为若干页，将物理内存空间分为若干页框，通过页表便能把连续的虚拟内存，映射到若干个不连续的物理内存页。这样就解决了使用连续的物理内存造成的碎片问题。

2、物理内存管理

假设一个可用的物理内存有 4GB 的空间。按照一个页框的大小 4KB进行划分，4GB的空间就是4GB / 4KB = 1048576个页框。有这么多的物理页，操作系统肯定是要将其管理起来的，操作系统需要知道哪些页正在被使用，哪些页空闲等等。

struct page结构

内核用struct page结构表示系统中的每个物理页，出于节省内存的考虑，struct page中使用了大量的联合体union。

struct page
{// ....
};

其中比较重要的几个参数：

1、flags：用来存放页的状态。这些状态包括页是不是脏的，是不是被锁定在内存中等。flag的每一位单独表示一种状态，所以它至少可以同时表示出32种不同的状态。这些标志定义在<linux/page-flags.h>中。其中一些比特位非常重要，如PG_locked用于指定页是否锁定，PG_uptodate用于表示页的数据已经从块设备读取并且没有出现错误。

#define 未使用 (1<<0)
#define 正在使用 (1<<1)
#define 被锁定在内存中 (1<<2)
....

2、_mapcount：表示在页表中有多少项指向该页，也就是这一页被引用了多少次。当计数值变为-1时，就说明当前内核并没有引用这一页，于是在新的分配中就可以使用它。

3、virtual：是页的虚拟地址。通常情况下，它就是页在虚拟内存中的地址。有些内存（即所谓的高端内存）并不永久地映射到内核地址空间上。在这种情况下，这个域的值为NULL，需要的时候，必须动态地映射这些页。

page 结构管理数组

在 Linux 内核中实际上存在一个这样的数组 struct page mem_map[N] ，用该数组将每个页结构组织管理起来，将对页结构的管理转换为对数组这样的数据结构的增删查改工作。

在数组中，每个 page 结构都有自己的下标，而每个下标和page的地址可以相互转换：

• 物理地址 = 下标 * 4KB
• 下标 = 物理地址 / 4KB

既然 page 是用于描述物理内存的，则可以理解成：只要找到了 page，page 有下标，就等同于找到了物理内存!!

因此我们之前学习的：文件缓冲区，其实就是一个 page 的列表！！！

page 结构的内存存储

要注意的是struct page与物理页相关，而并非与虚拟页相关。而系统中的每个物理页都要分配一个这样的结构体，让我们来算算对所有这些页都这么做，到底要消耗掉多少内存。

假设struct page占 40 个字节的内存吧，假定系统的物理页为 4KB 大小，系统有 4GB 物理内存。那么系统中共有页面1048576个（1兆个），所以描述这么多页面的page结构体消耗的内存只不过 40MB，相对系统 4GB 内存而言，仅是很小的一部分罢了。因此，要管理系统中这么多物理页面，这个代价并不算太大。

要知道的是，页的大小对于内存利用和系统开销来说非常重要，页太大，页页必然会剩余较大不能利用的空间（页内碎片）。页太小，虽然可以减小页内碎片的大小，但是页太多，会使得页表太长而占用内存，同时系统频繁地进行页转化，加重系统开销。因此，页的大小应该适中，通常为512B - 8KB，Windows 系统的页框大小为 4KB。

3、页表

虚拟地址空间

实际上没有真正的存储资源的虚拟地址空间，虚拟地址空间中全是一个个虚拟地址，通过页表映射到物理地址空间

物理地址空间是实际的物理内存，由RAM组成，每个物理地址直接对应一个物理内存单元，因此可以真正存储数据

页表中的每一个表项，指向一个物理页的开始地址。在 32 位系统中，虚拟内存的最大空间是 4GB，这是每一个用户程序都拥有的虚拟内存空间。既然需要让 4GB 的虚拟内存全部可用，那么页表中就需要能够表示这所有的 4GB 空间，那么就一共需要 4GB / 4KB = 1048576 个表项。如下图所示：

虚拟内存看上去被虚线“分割”成一个个单元，其实并不是真的分割，虚拟内存仍然是连续的。这个虚线的单元仅仅表示它与页表中每一个表项的映射关系，并最终映射到相同大小的一个物理内存页上。

页表中的物理地址，与物理内存之间，是随机的映射关系，哪里可用就指向哪里(物理页)。虽然最终使用的物理内存是离散的，但是与虚拟内存对应的线性地址是连续的。处理器在访问数据、获取指令时，使用的都是线性地址，只要它是连续的就可以了，最终都能够通过页表找到实际的物理地址。

引入多级页表思想：

在32位系统中，地址的长度是4个字节，那么页表中的每一个表项就是占用4个字节。所以页表占据的总空间大小就是：1048576 * 4 = 4MB 的大小。也就是说映射表自己本身，就要占用4MB / 4KB = 1024个物理页。这会存在哪些问题呢？

• 回想一下，当初为什么使用页表，就是要将进程划分为一个个页可以不用连续的存放在物理内存中，但是此时页表就需要1024个连续的页框，似乎和当时的目标有点背道而驰了……
• 此外，根据局部性原理可知，很多时候进程在一段时间内只需要访问某几个页就可以正常运行了。因此也没有必要一次让所有的物理页都常驻内存。
  
  

解决需要大容量页表的最好方法是：把页表看成普通的文件，对它进行离散分配，即对页表再分页，由此形成多级页表的思想。

为了解决这个问题，可以把这个单一页表拆分成1024个体积更小的映射表。如下图所示。这样一来，1024（每个表中的表项个数）* 1024（表的个数），仍然可以覆盖4GB的物理内存空间。

---

这里的每一个表，就是真正的页表，所以一共有1024个页表。一个页表自身占用4KB，那么1024个页表一共就占用了4MB的物理内存空间，和之前没差别啊？

从总数上看是这样，但是一个应用程序是不可能完全使用全部的4GB空间的，也许只要几十个页表就可以了。例如：一个用户程序的代码段、数据段、栈段，一共就需要10 MB的空间，那么使用3个页表就足够了。

计算过程：
每一个页表项指向一个4KB的物理页，那么一个页表中1024个页表项，一共能覆盖4MB的物理内存；
那么10MB的程序，向上对齐取整之后（4MB的倍数，就是12MB），就需要3个页表就可以了。

总的来说，因为一个进程不可能用完所有物理内存，因此页表也不需要一次性开辟这么多，可能只需两三张页表就够用了，所以一个进程的页表结构是远远小于4MB的

4、页目录结构

到目前为止，每一个页框都被一个页表中的一个表项来指向了，那么这1024个页表也需要被管理起来。管理页表的表称之为页目录表，形成二级页表。如下图所示：

---

---

• 所有页表的物理地址被页目录表项指向。
• 页目录的物理地址被CR3寄存器指向，这个寄存器中，保存了当前正在执行任务的页目录地址。

所以操作系统在加载用户程序的时候，不仅仅需要为程序内容来分配物理内存，还需要为用来保存程序的页目录和页表分配物理内存。

5、两级页表的地址转换

下面以一个逻辑地址为例。将逻辑地址（000000000000, 000000000001, 111111111111）转换为物理地址的过程：

1、在32位处理器中，采用 4KB 的页大小，则虚拟地址中低 12 位为页偏移，剩下高 20 位给页表，分成两级，每个级别占 10 个 bit（10+10）。

2、CR3 寄存器读取页目录起始地址，再根据一级页号查页目录表，找到下一级页表在物理内存中存放位置。

3、根据二级页号查表，找到最终想要访问的内存块号。

4、结合页内偏移量得到物理地址。

---

---

简单来说，在32位处理器中，一个页大小为 4 KB，等于 4 * 1024 字节，给每个字节分配一个位置，则需要用一个 12 位的数据来表示（4 * 1024 = 2^12 = 12 位），因此可以用数据的 12 个比特位表示一个页，而在32位处理器中，一个地址的大小为 32 位，则用该地址的低 12 位表示一个具体的页内地址。

前面文章讲解了，本系统使用的是 二级页表结构，一个页目录表包含 1024 个页表，一个页表包含 1024 个页地址，因此，我们可以用 10 位比特表示 页目录表 的表号，用于索引页目录表中的某个具体的页表，接着再用 10 位比特表示 一个页表 的表号，用于索引页表中的某个页地址，此处我们需要的 20 位比特位不就刚好可以从 一个地址 的高 20 位中取吗？

综上所述，在32位处理器中，一个地址的高 20 位用于表示 页目录表 和 页表中的索引号，低 12 位表示一个具体的页内地址。

5、页框的首地址的低12位为 0

一个物理页的地址一定是 4KB 对齐的，低12位是用于表示整个 4KB 的，因此页框的首地址的低12位为 0，因而页表只需 20 个比特位就够了，因为低12位不用存

看一下内核源码：你可以发现页表本质上就是一个 unsigned long 类型的数组！！

---

---

但是 unsigned long 这 32 位中的低 12 位总不能闲置吧

页表项剩下的 12 个比特位存储的就是页表条目的各种标记位：权限、命中……！！！！

---

---

再查看源码：页表标志位的源码，可以看到就是 0~11 共 12 位！！！！

---

因此，对于页表来说，每个页表项存储着一个物理地址，该物理地址数据的前 20 位用于存储实际的页框的首地址，后 12 位存储标志位！（页表目录没有这所谓的标志位，因为页表目录的目录项存储的地址就完整的指向下一级的页表或页表目录）

6、以上其实就是MMU的工作流程。

MMU (Memory Manage Unit) 是一种硬件电路，其速度很快，主要工作是进行内存管理，地址转换只是它承接的业务之一。

到这里其实还有个问题：MMU 要先进行两次页表查询确定物理地址，在确认了权限等问题后，MMU再将这个物理地址发送到总线，内存收到之后开始读取对应地址的数据并返回。那么当页表变为N级时，就变成了 N 次检索 +1 次读写。可见，页表级数越多查询的步骤越多，对于CPU来说等待时间越长，效率越低。

让我们现在总结一下：单级页表对连续内存要求高，于是引入了多级页表，但是多级页表也是一把双刃剑，在减少连续存储要求且减少存储空间的同时降低了查询效率。

有没有提升效率的办法呢？

计算机科学中的所有问题，都可以通过添加一个中间层来解决。MMU 引入了新武器，江湖人称快表的 TLB（其实，就是缓存）

当 CPU 给 MMU 传新虚拟地址之后，MMU 先去问 TLB 那边有没有，如果有就直接拿到物理地址发到总线给内存，齐活。但 TLB 容量比较小，难免发生 Cache Miss，这时候 MMU 还有保底的老武器页表，在页表中找到之后 MMU 除了把地址发到总线传给内存，还把这条映射关系给到 TLB，让它记录一下刷新缓存。

再看虚拟地址空间

---

---

实际上，虚拟地址空间就是一块存储着许多的地址的内存空间，地址空间内也会以 4KB 为单位分区，实际上还是连续的，分区是为了好理解，这块空间中每个虚拟地址最终都会对应到具体一个字节的物理地址。

根据上图的知识点，因为虚拟地址是从 0x0000~0xFFFF，不可能每个具体的虚拟地址都能指向对应一个页表表项（占用内存没必要），因此每个4KB 的虚拟内存块的首位地址会指向一个页表表项，而该虚拟内存块的首位地址也就刚好通过页表表项映射到物理地址的一个页框的首位地址，虚拟地址的其他地址想要通过页表找到对应的物理内存地址，则是先通过该虚拟地址的高10 位地址查询页表目录，次高 10 位地址查询二级页表，剩下的低 12 位地址则作为偏移量，与在二级页表中查到的物理地址的一个页框的首位地址相加，最后得到该虚拟地址的真正对应物理地址！

虚拟地址到物理地址的映射

1. 虚拟地址空间：
   • 虚拟地址空间通常为 4GB（ 32 位地址空间），从 0x00000000 到 0xFFFFFFFF。
   • 每个虚拟地址被划分为多个4KB大小的页。
2. 页表结构：
   • 页表通常采用多级结构，如两级页表或多级页表。
   • 每个页表项包含物理页的起始地址和其他信息（如有效位、读写权限等）。

两级页表（以32位地址为例）

1. 虚拟地址的划分：
   • 32位地址空间被划分为页，每页4KB。
   • 每个页的大小为4KB，即 212212 字节。
2. 页表项的结构：
   • 一级页表（Page Directory）：每个表项指向一个二级页表（Page Table）。
   • 二级页表：每个表项指向一个物理页。
3. 地址转换过程：
   • 高10位（第22-31位）：用于索引一级页表（Page Directory），选择一个二级页表。
   • 次高10位（第12-21位）：用于索引二级页表（Page Table），选择一个物理页。
   • 低12位（第0-11位）：作为偏移量，与物理页的起始地址相加，得到最终的物理地址。

这样通过：高10位、次高10位 索引页表，本质上是通过这 10 位，体现出来的数值，像数组下标一样索引页表“数组”，这样就是一种 O(1) 级别的算法，使得查询索引地址快速

通过这样索引页表得到页框物理地址+偏移量的方式就一定能找到某个字节的物理地址！！！

而这就为什么我们语言中数据都是有类型的，int 大小需要 4 字节，只需通过“连续偏移量”就能找到对应物理地址

根据地址，我们查询页表获得页框起始物理地址+页内偏移量的方式可以访问任何一个字节的物理地址位置

在这个物理位置基础上加上语言层面的各个类型的大小，就能连续访问获取整个大小数据类型的数据！

6、缺页异常

设想，CPU MMU 的虚拟地址，在 TLB 和页表都没有找到对应的物理页，该怎么办呢？其实这就是缺页异常 Page Fault，它是一个由硬件中断触发的可以由软件逻辑纠正的错误。

假如目标内存页在物理内存中没有对应的物理页或者存在但无对应权限，CPU 就无法获取数据，这种情况下 CPU 会报告一个缺页错误。

由于 CPU 有数据就无法进行计算，CPU 罢工了用户进程也就出现了缺页中断，进程会从用户态切换到内核态，并将缺页中断交给内核的 Page Fault Handler 处理。

缺页中断会交给 Page Fault Handler 处理，其根据缺页中断的不同类型会进行不同的处理：

• Hard Page Fault 也被称为 Major Page Fault，翻译为硬缺页错误/主要缺页错误，这时物理内存中没有对应的物理页，需要 CPU 打开磁盘设备读取到物理内存中，再让 MMU 建立虚拟地址和物理地址的映射。（也就是内存中没有该页面，页表中也没有）

• Soft Page Fault 也被称为 Minor Page Fault，翻译为软缺页错误/次要缺页错误，这时物理内存中是存在对应物理页的，只不过可能是其他进程调入的，发出缺页异常的进程不知道而已，此时 MMU 只需要建立映射即可，无需从磁盘读取写入内存，一般出现在多进程共享内存区域。（也就是内存中有该页面，但页表中没有）

• Invalid Page Fault 翻译为无效缺页错误，比如进程访问的内存地址越界访问，又比如对空指针解引用内核就会报 segment fault 错误中断进程直接挂掉。（也就是错误访问了）

---

7、虚拟地址到物理地址的相关转换

虚拟地址到物理地址的转换工作是由 MMU 完成的：

---

---

MMU 不会很复杂

对于 MMU 来说，因为仅仅是使用虚拟地址查页表这点操作，没必要用某种复杂的算法，因此注定了 MMU 的内部工作原理不会很复杂！

问题：这个地址转换工作是否可以使用软件来做？

答：原理简单当然可以用软件实现，但是软件太慢了，会导致大量的 CPU 周期浪费，CPU 通过虚拟地址得到物理地址的操作是需要进行很多次的，过于高频，硬件比软件快得多！

CPU的实模式和保护模式

CPU其实有一种实模式和保护模式，起初内存还未形成页表时，CPU为实模式：可以直接访问物理地址，而页表形成后就切换到保护模式，通过 MMU 查页表得到物理地址

CPU具体是如何访问物理内存

可以看这篇博客：【Linux系统】深入硬件：解析CPU如何访问物理内存-CSDN博客

8、页表条目的权限位

页表每个条目对应的物理地址，在页表状态栏中有权限位

下面这段修改一个字符串常量，会使程序崩溃： 是因为该代码在页表中条目的权限位为只读权限

CPU运行该程序时，MMU查询页表发现这个字符串为只读权限，因此修改常量字符串时MMU会报错，触发硬件中断，进入内核执行对应的中断处理例程，操作系统向该进程发送信号，杀掉该进程

char *message = "hello";
message[0] = "o";  // 报错！！！

在C++中，当你定义一个字符串常量（如 "hello"），它通常会被存储在程序的只读数据段或文本段中。这些段中的内存页面由操作系统设置为只读权限，以防止意外修改，确保程序的稳定性和安全性。

当你尝试通过指针 message 修改这个字符串常量时，实际上是在尝试修改位于只读内存区域的数据。现代CPU和操作系统使用内存管理单元（MMU）来管理和保护内存。当程序尝试对只读内存进行写操作时，MMU会检测到这一违反权限的行为，并触发一个异常（在x86架构上这通常是一个页错误或段错误）。

具体来说，以下是发生的过程：

1. 程序执行：程序试图执行 message[0] = 'o';，这意在修改字符串的第一个字符。
2. MMU检查：MMU查询页表，发现该地址对应的页面权限是只读的。
3. 触发异常：由于尝试对只读页面进行写入操作，MMU触发一个硬件中断，通常是页错误（Page Fault）或段错误（Segmentation Fault）。
4. 进入内核模式：CPU切换到内核模式，操作系统接管并处理这个中断。
5. 中断处理：操作系统执行相应的中断处理例程（ISR），检查错误类型。
6. 信号发送：对于页错误或段错误，操作系统通常会向进程发送一个SIGSEGV信号（Segmentation Violation Signal）。
7. 进程终止：默认情况下，接收到SIGSEGV信号会导致进程被立即终止，从而避免潜在的不稳定状态。

修改只读数据触发的错误是什么类型的中断？

硬件中断 or 软件中断

简单来说：我认为，修改只读数据是由 MMU 这个硬件产生的异常，应该是硬件中断

当程序尝试修改位于只读页面中的字符串常量时，触发的是硬件中断。具体来说，这是由内存管理单元（MMU）检测到权限违规而引发的**页错误（Page Fault）或段错误（Segmentation Fault）**以下是更详细的解释：

硬件中断 vs. 软件中断

1. 硬件中断：
   • 定义：由硬件设备（如I/O设备、定时器、MMU等）触发的中断。
   • 特点：通常是由于外部事件或硬件检测到异常情况而产生的。例如，MMU检测到非法内存访问、CPU检测到除零错误等。
   • 触发机制：硬件设备通过中断请求线（IRQ）向CPU发出信号，CPU响应并处理这些中断。
2. 软件中断：
   • 定义：由软件指令（如 int 指令、系统调用等）显式触发的中断。
   • 特点：通常用于请求操作系统服务或执行特定的操作。例如，用户程序通过系统调用请求文件操作、进程创建等。
   • 触发机制：程序执行特定的指令来引发中断，CPU根据中断向量表（IVT）跳转到相应的中断处理例程。

程序在页表上的权限是何时被设置的？

答：在加载的时候，可执行程序在编译时就已经划分好了数据段和代码段！

1、链接器和编译器的角色

• 编译阶段：当程序被编译时，编译器会根据代码和数据的不同特性，将它们划分为不同的段（section）。例如，代码段（.text）通常包含程序的执行指令，而数据段（如 .data 和 .bss）则包含全局变量和静态变量。
• 链接阶段：链接器负责将编译后的目标文件组合成一个可执行文件。它会根据各个段的属性，确定哪些段应该被标记为只读（如代码段），哪些段应该是可读写的（如数据段）。

2、加载器的角色

• 加载阶段：当操作系统启动一个程序时，加载器（Loader）负责将可执行文件从磁盘加载到内存中。在这个过程中，加载器会读取可执行文件的元数据（如ELF或PE格式的头部信息），这些元数据包含了每个段的起始地址、大小以及访问权限。
• 创建页表项：加载器会根据这些元数据，在页表中为每个段创建相应的页表项，并设置适当的权限标志位。例如：
  • 代码段：通常会被设置为只读（Read/Execute, RX），以防止代码被意外修改。
  • 数据段：通常会被设置为可读写（Read/Write, RW），以便程序可以修改这些数据。
  • 堆和栈：通常会被设置为可读写（RW），并且栈可能还会被设置为不可执行（No Execute, NX），以防止栈溢出攻击。