On page fault, how does Unix determine if the faulting address is in swap space?

Question

When a page fault occurs for a virtual address for any process how does the linux/unix operating system determine whether that page (of that virtual address) was swapped previously present in memory and swapped out to disk (i.e. that page is currently present in swap space) or that page was never loaded to memory before (i.e. that page is not present in swap space)?

Answer 1

First we need to look at what happens at the hardware level. A page fault happens when the MMU attempts to dereference a virtual address and finds an invalid descriptor for that address. When this happens, the processor executes a trap: it switches to kernel mode, jumps to a predefined address (the trap vector) and fills in some registers to indicate that a page fault happened, and enough information to allow the kernel to determine what the requested address was, what instructions caused the fault, and in what task. I'm giving the general idea here, the concrete details vary between processor architectures.

The trap handler code, which is part of the kernel, examines registers and memory to determine the nature of the fault (the same handler may be invoked for different types of exceptions), the requested address and which process that was previously active. It then consults some data structures that indicate what is supposed to be mapped in that process at that address. Here again the nature of the data structure varies between processor architectures, and also between Unix variants. Some processor architectures have enough bits in an invalid descriptor that aren't interpreted by the MMU to store a swap sector number, in which case the kernel doesn't need to consult any other data structure. If this is not the case, the kernel will consult a data structure that's attached to the process and describes its memory mappings.

The same mechanism may also determine several other things, such as:

• The page needs to be loaded from a file, for memory-mapped files.
• The memory is mapped but the operation was not authorized, e.g. it was an attempt to write to read-only memory. In this case, the kernel arranges to switch control to the process's SIGSEGV signal if it has one, and otherwise the process is terminated.
• An attempt was made to write to a page that is marked as read-only for the CPU, but marked as copy-on-write. In that case the kernel makes a copy of the page.

If the kernel manages to obtain a page in RAM that has the content that the process expects, it updates the process's memory map to reflect that. Then the kernel transfers control back to the process, like on a context switch; but instead of returning control just after the instruction that the process executed, it returns control just before this instruction, so that the faulting instruction is executed again, this time successfully.

Answer 2

The low level page fault handler in the OS (that is listed in the trap table from the CPU) get's the fault address from the CPU and uses this fault address to check the entries in process's address space description table. This table contains a list of segment descriptors that each contain a base address and a size. If the address is not in that list. the OS sends a SIGSEGV (segmentati violati).

If the address could be found, the segment table entry that is responsible for the address range that includes the fault address also holds a pointer to the driver functions of the related segment driver.

A segment driver manages the VMEM to background memory actions. If the address is related to swap space, then the name of the responsible driver is anon.

There are many segment drivers, e.g. a segment driver for every filesystem as basically all filesystem data I/O operations are handled via mmap().