我发现在TLB丢失过程中，有些体系结构使用硬件来处理它，而有些体系结构则使用操作系统。但当涉及到页面错误时，大多数都使用操作系统而不是硬件。
我试图找到答案，但没有找到任何文章解释原因。
有人可以帮忙解决这个问题吗？
谢谢。
如果硬件能够自行处理它，就不需要出现故障。
重点是操作系统尚未将页面连接到硬件页表中，例如因为它实际上根本不在内存中，或者因为操作系统需要捕获写入尝试，以便操作系统可以实现写时复制。
页面错误分为三类：
-
valid (the process logically has the memory mapped, but the OS was lazy or playing tricks):
- 硬：页面需要从磁盘调入，无论是从交换空间还是从磁盘文件（例如内存映射文件，如可执行文件或共享库的页面）。通常操作系统会在等待 I/O 的同时调度另一个任务。
- 软：不需要磁盘访问，例如分配+清零一个新的物理页来支持用户空间刚刚尝试写入的虚拟页。或者是多个进程映射的可写页面的写时复制，但其中一个进程的更改不应对另一个进程可见（例如 mmap(MAP_PRIVATE)）。这会将共享页面变成私有脏页面。
-
invalid：该页面甚至没有逻辑映射。像 Linux 这样的 POSIX 操作系统会将 SIGSEGV 信号传递给有问题的进程/线程。
硬件不知道哪个是哪个，它只知道页面遍历没有找到该虚拟地址的有效页表条目，因此是时候让操作系统决定下一步做什么。 （即引发运行操作系统页面错误处理程序的页面错误异常。）有效/无效纯粹是软件/操作系统概念。
这些示例原因并不是详尽的列表。例如操作系统可能会删除页面的硬件映射，而不实际将其调出，只是为了看看进程是否很快会再次触及它。 （在这种情况下，这只是一个廉价的软页面错误。但如果不是，那么它实际上可能会将其分页到磁盘。或者如果它是干净的，则将其删除。）
为了使硬件能够完全处理页面错误，我们需要具有硬件指定布局的数据结构，以某种方式让硬件知道在某些可能的情况下要做什么。除非你将整个内核构建到CPU微码中，否则不可能让它处理every页面错误，尤其是需要读取操作系统的进程/任务管理数据结构并向用户空间传递信号的无效页面错误。要么发送给信号处理程序（如果有），要么终止该进程。
尤其不是硬页面错误，多任务操作系统会让其他进程运行，同时等待磁盘将页面 DMA 写入内存，然后为此进程连接页表并让它重试错误加载或存储指令。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
