为什么页面错误通常由操作系统而不是硬件处理? [英] Why page faults are usually handled by the OS, not hardware?

问题描述

我发现在缺少TLB的过程中，某些体系结构使用硬件来处理它，而另一些使用OS.但是，当涉及到页面错误时，大多数人都使用操作系统而不是硬件.

I find that during TLB missing process, some architecture use hardware to handle it while some use the OS. But when it comes to page fault, most of them use the OS instead of hardware.

我试图找到答案，但没有找到任何说明原因的文章.

I tried to find the answer but didn't find any article explains why.

有人可以帮忙吗?谢谢.

Could anyone help with this? Thanks.

推荐答案

如果硬件可以自行处理，则无需出错.

If the hardware could handle it on its own, it wouldn't need to fault.

整个问题是操作系统尚未将页面连接到硬件页面表中，例如因为它实际上根本不在内存中，或者是因为OS需要捕获写入尝试才能使OS实现写时复制.

The whole point is that the OS hasn't wired the page into the hardware page tables, e.g. because it's not actually in memory at all, or because the OS needs to catch an attempt to write so the OS can implement copy-on-write.

页面错误分为三类:

• valid (该进程在逻辑上已映射了内存，但是操作系统很懒惰或在玩弄花招):
  • hard:页面需要从磁盘(从交换空间)或磁盘文件(例如，内存映射文件，例如可执行文件或共享库的页面)中进入页面.通常，操作系统将在等待I/O时安排另一个任务.
  • soft:不需要磁盘访问，例如分配+调零新的物理页面以支持用户空间刚刚尝试写入的虚拟页面.或写有多个进程已映射的可写页面的写时复制，但是其中一个对象的更改对另一个对象不可见(例如mmap(MAP_PRIVATE)).这会将共享页面变成私有脏页面.
  • valid (the process logically has the memory mapped, but the OS was lazy or playing tricks):
    • hard: the page needs to be paged in from disk, either from swap space or from a disk file (e.g. a memory mapped file, like a page of an executable or shared library). Usually the OS will schedule another task while waiting for I/O.
    • soft: no disk access required, just for example allocating + zeroing a new physical page to back a virtual page that user-space just tried to write. Or copy-on-write of a writeable page that multiple processes had mapped, but where changes by one shouldn't be visible to the other (like mmap(MAP_PRIVATE)). This turns a shared page into a private dirty page.

    硬件不知道哪个是哪个，它所知道的只是页面遍历找不到该虚拟地址的有效页表条目，因此现在是让操作系统决定下一步操作的时候了.(即引发运行OS的页面错误处理程序的页面错误异常.)有效/无效纯粹是软件/操作系统的概念.

    The hardware doesn't know which is which, all it knows was that a page walk didn't find a valid page-table entry for that virtual address, so it's time to let the OS decide what to do next. (i.e. raise a page-fault exception which runs the OS's page-fault handler.) valid/invalid are purely software/OS concepts.

    这些示例原因并不是详尽的清单.例如操作系统可能会删除页面的硬件映射而没有实际将其分页出来，只是为了查看进程是否很快再次触及该页面.(在这种情况下，这只是廉价的软页面错误.但是，如果不是，那么它实际上可能会将其分页到磁盘上.如果干净，则将其丢弃.)

    These example reasons are not an exhaustive list. e.g. an OS might remove the hardware mapping for a page without actually paging it out, just to see if the process touches it again soon. (In which case it's just a cheap soft page fault. But if not, then it might actually page it out to disk. Or drop it if it's clean.)

    要使硬件能够完全处理页面错误，我们需要具有硬件指定布局的数据结构，该布局可以以某种方式让硬件知道在某些可能情况下的处理方法.除非您将整个内核构建到CPU微代码中，否则不可能处理每页错误，尤其是无效的错误，这些错误需要读取OS的进程/任务管理数据结构并向用户空间.如果有的话，要么给信号处理程序，要么杀死进程.

    For HW to be able to fully handle a page fault, we'd need data structures with a hardware-specified layout that somehow lets hardware know what to do in some possible situations. Unless you build a whole kernel into the CPU microcode, it's not possible to have it handle every page fault, especially not invalid ones which require reading the OS's process / task-management data structures and delivering a signal to user-space. Either to a signal handler if there is one, or killing the process.

    尤其是非硬页错误，在此过程中，在为该过程连接页表并使其重试之前，多任务操作系统将在等待磁盘将页面DMA到内存中的同时让其他进程运行错误的加载或存储指令.

    And especially not hard page faults, where a multi-tasking OS will let some other process run while waiting for the disk to DMA the page(s) into memory, before wiring up the page tables for this process and letting it retry the faulting load or store instruction.

    这篇关于为什么页面错误通常由操作系统而不是硬件处理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！