为什么页面错误通常由操作系统而不是硬件处理？答案

【问题标题】：Why page faults are usually handled by the OS, not hardware?为什么页面错误通常由操作系统而不是硬件处理？
【发布时间】：2020-07-04 14:29:39
【问题描述】：

我发现在 TLB 丢失过程中，一些架构使用硬件来处理它，而一些使用操作系统。但是当涉及到页面错误时，他们中的大多数使用操作系统而不是硬件。

我试图找到答案，但没有找到任何解释原因的文章。

有人可以帮忙吗？谢谢。

【问题讨论】：

硬件如何知道该做什么？必要的操作可能是从任意 I/O 设备读取页面，或在写入时复制页面，或终止进程，或任何其他复杂的操作。硬件不知道需要哪些东西，也不知道如何去做。它所能做的就是通知软件（操作系统）并让它解决。

标签： operating-system paging cpu-architecture virtual-memory page-fault

【解决方案1】：

如果硬件可以自己处理它，它就不需要出错。

关键是操作系统没有将页面连接到硬件页表中，例如因为它实际上根本不在内存中，或者因为操作系统需要捕获写入尝试以便操作系统可以实现写时复制。

页面错误分为三类：

有效（进程在逻辑上映射了内存，但操作系统很懒惰或在耍花招）：
- hard：页面需要从磁盘调入，可以是从交换空间或磁盘文件（例如，内存映射文件，如可执行文件或共享库的页面）。 通常操作系统会在等待 I/O 时安排另一个任务。
- soft：不需要磁盘访问，例如分配 + 归零一个新物理页面以支持用户空间刚刚尝试写入的虚拟页面。或者写时复制多个进程已映射的可写页面，但其中一个进程的更改不应该对另一个进程可见（如 mmap(MAP_PRIVATE)）。这会将共享页面变成私有脏页面。
无效：该页面甚至没有逻辑映射。像 Linux 这样的 POSIX 操作系统会将 SIGSEGV 信号传递给有问题的进程/线程。

硬件不知道哪个是哪个，它只知道页面遍历没有找到该虚拟地址的有效页表条目，所以是时候让操作系统决定下一步该做什么了。（即引发运行操作系统的页面错误处理程序的页面错误异常。）有效/无效是纯粹的软件/操作系统概念。

这些示例原因并非详尽无遗。例如操作系统可能会删除页面的硬件映射而不实际分页，只是为了查看进程是否很快再次触及它。（在这种情况下，它只是一个廉价的软页面错误。但如果不是，那么它实际上可能会将其分页到磁盘。或者如果它是干净的，则将其丢弃。）

为了让硬件能够完全处理页面错误，我们需要具有硬件指定布局的数据结构，以某种方式让硬件知道在某些可能的情况下应该做什么。除非您将整个内核构建到 CPU 微码中，否则不可能让它处理每个页面错误，尤其是需要读取操作系统的进程/任务管理数据结构并向其发送信号的无效页面错误用户空间。如果有信号处理程序，或者终止进程。

尤其不是硬页错误，在这种情况下，多任务操作系统会让其他进程运行，同时等待磁盘将页面 DMA 到内存中，然后为该进程连接页表并让它重试错误的加载或存储指令。

【讨论】：