我发现在TLB丢失过程中，有些体系结构使用硬件来处理它，而有些则使用操作系统。但当涉及到页面故障时，他们中的大多数人都使用操作系统而不是硬件。
我试图找到答案，但没有找到任何解释原因的文章。
有人能帮忙吗？谢谢
如果硬件可以自己处理，就不需要出错。
关键是操作系统没有将页面连接到硬件页面表中，例如，因为它实际上根本不在内存中，或者因为操作系统需要捕获写入尝试，以便操作系统可以实现写时复制。
页面错误分为三类：
-
有效(进程逻辑上映射了内存，但操作系统懒惰或耍花招(：
- hard：页面需要从磁盘分页，无论是从交换空间还是从磁盘文件(例如，内存映射文件，如可执行文件或共享库的页面(通常操作系统会在等待I/O时安排另一项任务
- soft：不需要磁盘访问，例如，分配+清零一个新的物理页面，以支持用户空间刚刚尝试写入的虚拟页面。或者在写时复制多个进程映射的可写页面，但其中一个进程的更改对另一个进程不可见(如mmap(MAP_PRIVATE((。这会将共享页面变成私人脏页面
- 无效：该页面甚至没有逻辑映射。像Linux这样的POSIX操作系统将向有问题的进程/线程传递SIGSEGV信号
硬件不知道哪个是哪个，只知道页面遍历没有找到该虚拟地址的有效页面表条目，所以是时候让操作系统决定下一步该做什么了。(即引发运行操作系统页面错误处理程序的页面错误异常。(有效/无效纯粹是软件/OS的概念。
这些示例原因并非详尽无遗。例如，操作系统可能会删除页面的硬件映射，而不实际将其分页出去，只是为了看看进程是否很快再次触及它。(在这种情况下，这只是一个廉价的软页面故障。但如果不是，那么它可能会将其分页到磁盘上。或者，如果它是干净的，就将其丢弃。(
为了让硬件能够完全处理页面故障，我们需要具有硬件指定布局的数据结构，以某种方式让硬件知道在某些可能的情况下该做什么。除非将整个内核构建到CPU微码中，否则不可能让它处理每个页面错误，尤其是那些需要读取操作系统的进程/任务管理数据结构并向用户空间传递信号的无效错误。如果有信号处理程序，则将其发送到信号处理程序；或者终止进程。
尤其是硬页面错误，在等待磁盘将页面DMA到内存时，多任务操作系统会让其他进程运行，然后为该进程连接页面表，并让它重试错误的加载或存储指令。