demand paging

Picture a chef who could, in principle, lay out every ingredient in the pantry on the counter before starting to cook. That would be slow and wasteful — most dishes use only a handful of ingredients. A smarter chef fetches each ingredient from the pantry only at the moment the recipe first calls for it. Demand paging is the same idea for a running program: do not load any page of it into RAM until the moment the program actually touches that page. Load on demand, never in advance.

Concretely, a program's address space is divided into fixed-size pages. With demand paging, when the program starts, almost none of its pages are in RAM. Each page-table entry carries a valid-invalid bit: valid means the page is resident in a real frame, invalid means it is not in memory right now. When the program references a page whose bit is invalid, the hardware traps to the OS — this is a page fault. The OS finds the page on the backing store, loads it into a free frame (or evicts one to make room), flips the bit to valid, and restarts the faulting instruction. From the program's view nothing unusual happened; it just took longer than usual. As the program runs, the pages it actually uses trickle into RAM, while pages it never touches are never loaded at all.

Why it matters: demand paging is what makes virtual memory practical and cheap. It avoids wasting RAM and disk-read time on code and data the program may never use (think of error-handling routines that rarely run). It makes startup fast, since a program can begin executing with only its first few pages loaded. And it raises how many programs can share RAM. It works in practice only because of locality of reference: programs tend to use a small, slowly changing set of pages at a time, so the cost of a fault is amortized over many cheap in-memory accesses. Without locality, demand paging would fault constantly and crawl.