a page fault

Picture the receptionist looking up 'room 412' and finding the directory says 'not built / in storage.' The receptionist cannot just shrug — they pause the visitor, call the building crew to fetch and install the missing room, update the directory, and then let the visitor proceed as if nothing happened. A page fault is this pause-and-fetch event: the hardware tries to translate an address, finds the page is not present in physical memory, and traps to the operating system to handle it.

Concretely, on each access the MMU checks the page-table entry's valid bit. If it is 0, the page is not in any frame, so the hardware raises a page-fault exception that transfers control to the OS fault handler. The handler figures out where the page lives (often on disk), finds a free frame (evicting some other page if none is free, writing it back first if it is dirty), reads the page in from storage, updates the page-table entry to mark it valid and pointing at the new frame, and then restarts the faulting instruction — which now succeeds. The program resumes, oblivious. A protection violation also raises a fault, but that one usually ends the program rather than fixing anything.

Why it matters: page faults are what let a program use more memory than physically exists and start running before it is fully loaded — but they are extremely expensive. A fetch from disk is millions of CPU cycles; from an SSD, still tens of thousands. A handful of faults are invisible, but a program faulting constantly is thrashing and may run thousands of times slower. So page faults are simultaneously the feature that makes demand paging possible AND one of the worst things that can happen to performance — an honest reminder that virtual memory's convenience is not free.