Page Faults

The page walker reads a PTE with the present bit clear — or one whose permissions forbid the access (a write to a read-only page, an execute of an NX page, a user access to a supervisor page). The instruction cannot complete, so the CPU raises the page-fault exception: it records the faulting virtual address (CR2 on x86, FAR_EL1 on ARM) and an error code saying read/write/execute and user/kernel, saves the user state, and enters the kernel’s fault handler (User Mode vs Kernel Mode). The instruction is *not* finished; it will be restarted from scratch if the handler succeeds.

The kernel now has three facts — the address, the kind of access, the current process — and its own description of the process’s regions. From those it answers one question: is this a page that should exist, and if so where is its content? The rest of the handler is the answer.

A minor (soft) fault is one the kernel can resolve without waiting for I/O. The page was never touched and the region is anonymous: allocate a zeroed frame. The page belongs to a mapped file whose content is already in the page cache: point the PTE at that frame. The page is shared copy-on-write and the access is a write: allocate a frame, copy 4 kB, point the PTE at the copy (Copy-on-Write). The page was recently reclaimed but not yet reused (it is on the kernel’s inactive list or in the swap cache): just re-map it. All of these are a few hundred nanoseconds to a couple of microseconds of kernel work, and a running process incurs thousands to millions of them without anyone noticing.

A major (hard) fault needs data from a device: a file-mapped page not in the page cache, or an anonymous page that was written to swap. The handler issues the read and puts the process to sleep — it is not runnable until the I/O completes (Process States), and the scheduler runs something else. When the block layer’s completion interrupt fires, the page is filled, the PTE is written, the process is woken, and eventually rescheduled to retry its instruction. The cost is dominated by the device: ~100 µs on an NVMe SSD, 5–10 ms on a spinning disk, plus two context switches and whatever the scheduler queue adds. The kernel usually reads ahead (several pages around the faulting one) so that sequential access takes one major fault and many minor ones.

An invalid fault is an address outside every region, or an access the region’s permissions forbid (writing to code, executing data, the stack’s guard page in Stack Overflow). There is nothing to fix; the handler delivers SIGSEGV (or SIGBUS for a mapped-but-unbackable page) and the default action ends the process. Note that the CPU cannot distinguish the three: from its side every case is "present = 0" or "permission denied". The classification is entirely the kernel’s, made from its region list.

The property that makes all of this invisible is precise exceptions: the CPU guarantees that when the handler runs, every instruction before the faulting one has completed and the faulting one has had no effect. The handler changes only the page table; it returns to the *same* instruction pointer, and the load executes again — this time the walk finds a present entry and the value arrives. A store to a copy-on-write page is retried and lands in the private copy. A ten-instruction memcpy inner loop touching a fresh buffer faults once per page and never sees a difference except in the clock.

This is also how the kernel implements things that look impossible. Reading a 10 GB file with mmap and a for loop is a sequence of major and minor faults that the loop never sees (Memory Mapping). A process forked from a 10 GB parent shares every page until its first write to each. A user-space fault handler (userfaultfd on Linux) can even resolve faults from another process — how live migration of a VM copies memory lazily while the guest keeps running.

A minor fault is roughly a microsecond of kernel time — a trap, a region lookup, a frame allocation, a 4 kB zeroing (the expensive part, ~200–500 ns), a PTE write and the return. Touching a fresh 1 GB region is 262,144 of them: about a quarter of a second, which is why a freshly started process spends its first moments faulting and why pre-faulting exists (What Happens When I Allocate Memory?). A major fault is the device’s latency plus scheduling, so its cost is the I/O domain’s (Follow a File Read) and its rate is the number to watch: a process taking hundreds of major faults per second is being paged in from disk on every step, the first sign of Memory Pressure, Swap and the OOM Killer.

Both are counted per process and system-wide. /usr/bin/time -v prints them after a run; ps -o min_flt,maj_flt, perf stat -e page-faults,major-faults, and sar -B show them live. A program whose minor faults scale with the work it does is normal; one whose major faults are non-zero while the data should be in memory is swapping or has a page cache that is being evicted.