在进程上下文切换的情况下，新进程的虚拟地址空间（VAS）是否加载到 CPU 上下文（CPU 的寄存器）中？

Question

我已阅读：

进程切换是从一个进程到另一个进程的上下文切换。它涉及切换所有流程抽象和资源，以支持属于新流程的那些。最值得注意且代价高昂的是，这意味着切换内存地址空间。这包括内存地址、映射、页表和内核资源——这是一项相对昂贵的操作。

还有：

上下文是 CPU 寄存器和程序计数器在任何时间点的内容。

上下文切换可以稍微更详细地描述为内核（即操作系统的核心）针对 CPU 上的进程（包括线程）执行以下活动：（1）暂停一个进程的进程并将该进程的 CPU 状态（即上下文）存储在内存中的某个位置，（2）从内存中检索下一个进程的上下文并将其恢复到 CPU 的寄存器中，以及（3）返回到程序计数器指示的位置（即返回到中断进程的代码行）以恢复进程。

由于 VAS 对于每个进程都是独立的，并且最大大小可达 4GB，因此在上下文的情况下，进程的整个 VAS 是否会加载到 CPU 上下文中进程切换？

由于每个进程都有单独的页表，页表是否也被带入CPU上下文以防上下文切换？

如果不是，那么为什么进程上下文切换比线程上下文切换慢（线程共享相同的VAS）？

Answer 1

由于每个进程的 VAS 是独立的，最大可达 4GB，在进程上下文切换的情况下，一个进程的整个 VAS 是否会加载到 CPU 上下文中？

同样每个进程都有单独的页表，如果上下文切换，页表是否也在CPU上下文中购买？

这些问题是相关的。您 将一个虚拟地址空间换成另一个虚拟地址空间，方法是更改​​哪一组页表正在执行虚拟-> 线性转换。这样就完成了地址空间交换。

让我们考虑一个非常简单的例子。

• 假设我们有两个进程 P_A 和 P_B。两个进程都在虚拟地址 0x1000 处执行它们的程序映像。
• 对进程不可见的是一组页表，它们将虚拟地址空间映射到 RAM 的物理页：
  • Pagetable T_A 将虚拟地址 0x1000 映射到物理地址 0x88000
  • Pagetable T_B 将虚拟 0x1000 映射到物理 0x99000。
• 假设理论上的 CPU 有一个名为 PP（页表指针）的寄存器

在进程初始化后，在两者之间“交换虚拟地址空间”很简单。要加载 P_A 的地址空间，您只需将 T_A 的地址放入 PP，现在该进程“看到”内存为 0x88000。同样的，T_B 的地址是 P_B，所以他会“看到”内存在 0x99000。

在（同一进程的）线程之间切换时，不需要更改虚拟地址空间（因为给定进程的所有线程共享相同的虚拟地址空间）。

当然还有其他需要交换的东西（比如 CPU 寄存器），但在本次讨论中，我们只关心虚拟内存。

在 x86 CPU 上，CR3 寄存器是指向页表层次结构基础的指针。在交换进程时，操作系统会更改此寄存器以更改地址空间。

---

当然，比这更复杂。因为可能的虚拟地址空间非常大（x86-32 上为 4 GiB，x86-64 上为 16 exabytes），页表本身会占用大量空间（每 4 KiB 页面）。为了缓解这种情况，向页表添加了额外的间接级别，这就是我将它们称为层次结构的原因。在 x86-64 上，有 4 个级别。

现在想象一下，如果 CPU 必须为每个虚拟到物理的转换“遍历”这些分页结构。从虚拟内存中读取一次总共需要 5 次内存访问！这会非常慢。

输入 Translation lookaside buffer 或 TLB。 TLB 缓存这些翻译，因此给定的虚拟到物理的翻译只需要遍历一次页表。之后，TLB 会记住翻译，并且速度要快得多。 （当然 TLB 可以满，但缓存驱逐是另一回事）。

假设 P_A 正在运行，突然内核在地址空间中交换 P_B。现在所有这些缓存的虚拟到物理的转换对于新的虚拟地址空间不再有效！这意味着我们需要刷新 TLB，或者清除它的所有条目。因此，CPU 不得不再次进行缓慢的页表遍历，直到 TLB 缓存再次“升温”。

这就是为什么交换虚拟地址空间被认为是“昂贵的”。不是因为写信给CR3 很困难，而是因为我们每次都在浪费 TLB。