Page faults

A page fault is the CPU telling the kernel "I could not translate this address" — either no page-table entry exists or the permission bits forbid the access. Control traps into the kernel’s fault handler, which looks at the process’s mapping list to decide what the access *should* mean (Page Faults).

Three outcomes. A minor fault: the page is legitimately part of the address space but not yet mapped — the first touch of freshly malloced memory (the kernel hands out a zeroed frame), a page of a file that is already in the page cache, a shared-library page another process already loaded, or a copy-on-write page that must now be duplicated. Cost: a microsecond or a few. A major fault: the data is not in RAM and must come from storage — a file page not cached, or a page that was swapped out. Cost: ~100 µs on an SSD, ~10 ms on a spinning disk, during which the thread is blocked. An invalid fault: the address is not mapped at all or the access violates permissions (writing to code, dereferencing null) — the kernel delivers SIGSEGV.

So no, faults are not bad; they are the mechanism of demand paging. malloc(1 GB) returns instantly because nothing is mapped; the process then takes 262,144 minor faults as it touches the pages. Program start-up is a burst of faults as code pages are mapped from the executable. What *is* bad is a stream of major faults — that means the working set does not fit and the process is waiting on disk (Memory Pressure, Swap and the OOM Killer).

To tell: ps -o min_flt,maj_flt, /usr/bin/time -v (major/minor faults), perf stat -e page-faults,major-faults -p <pid>, sar -B for system-wide majflt/s (label: Linux). A process that is slow with high majflt/s and wa in top is memory-bound, not CPU-bound; a process taking millions of minor faults per second is allocating and freeing pages in a churn (an allocator returning memory to the kernel too eagerly, or huge fresh buffers per request).