prepaging

Imagine a waiter who, instead of walking to the kitchen each time you ask for the next dish, notices you always order the soup, then the main, then dessert in sequence — so he brings out the next course just before you finish the current one. He guesses what you will want and fetches it ahead of time, so you rarely wait. Prepaging is the OS playing this anticipating waiter: bringing pages into memory before they are referenced, guessing they will be needed soon, to avoid the stall of a fault at the moment of use.

Concretely, prepaging loads a group of pages into frames in advance, rather than waiting for each one to be demanded by a fault. The classic motivation is the start-up of a process under pure demand paging, where the first references cause a flurry of faults; prepaging brings in a batch of likely-needed pages at once so those many faults collapse into fewer, larger disk reads. The same idea applies when resuming a swapped-out process (bring its whole prior working set back together) or when spatial locality suggests that touching one page means nearby pages will be wanted too (read-ahead). The bet rests on prediction: prepaging pays off only if most of the pages it guesses really do get used.

Why it matters: prepaging trades certainty for speed. Demand paging never loads a page that is not needed, but it pays a fault each first time; prepaging amortizes start-up cost by batching, and a few big sequential disk reads are far more efficient than many scattered single-page reads. The honest catch is the gamble: if the predicted pages are wrong, prepaging wastes disk bandwidth and frames on pages that go untouched, possibly evicting useful pages to make room. So it helps when access is predictable (sequential scans, restoring a known working set) and hurts when it is not. It is the practical complement to pure demand paging, softening the start-up fault storm without abandoning lazy loading as the default.