Page Faults¶

graph TD fault["Page fault"] --> valid{"Virtual address mapped?"} valid -->|"no"| sig["Invalid: SIGSEGV"] valid -->|"yes, but not in RAM"| major["Major fault: load from disk (~ms)"] valid -->|"yes, in RAM but not in THIS process's table (CoW)"| minor["Minor fault: map it (~microseconds)"]

Minor: page in RAM but not mapped in this process's page table. CoW trigger. No disk I/O. Cost: ~microseconds.

Major: page not in RAM; loaded from disk. Blocks thread for milliseconds. Cause: memory pressure → swap, or file-backed mmap first access.

Invalid (SIGSEGV): virtual address not mapped. Null pointer dereference (address 0 unmapped), stack overflow (hits guard page), use-after-free (page unmapped by allocator).

Worked example — minor fault via fork: a process with a 2GB heap calls fork(). The child gets its own page table, but every entry points at the same physical pages as the parent, all marked read-only, copy-on-write. The child writes to one variable on a heap page — this triggers a minor fault: no disk I/O needed, the kernel just allocates a new physical page, copies the one 4KB page's contents, updates the child's page table entry to point at the copy, and marks it writable. Cost: microseconds. The other ~2GB of unmodified pages stay shared between parent and child for as long as neither writes to them.

Worked example — major fault under memory pressure: that same process's working set grows until the machine is low on RAM, and the kernel swaps some of its heap pages out to disk to make room. Later, the process reads a variable that lives on a swapped-out page. This triggers a major fault: the kernel must find the page on the swap device, issue a disk read, and block the thread until the read completes — milliseconds, roughly 1,000× slower than the minor-fault case, because it's bounded by disk I/O instead of a local memory copy. A process that faults like this repeatedly (thrashing) can spend more wall-clock time waiting on page-ins than doing actual work.