the working set

Watch how you actually use a big kitchen: at any given stretch of cooking you reach for only a handful of tools and ingredients over and over, even though the cupboards hold hundreds. That small, currently-hot collection is your working set, and it shifts as you move from chopping to frying to plating. For a running program, the working set is the set of pages it is actively using in the current phase of execution — a small, slowly-drifting subset of its whole address space.

Concretely, the working set is defined over a recent window of time: the pages the program has touched in, say, the last few hundred thousand instructions. Programs have locality, so this set is usually far smaller than the program's total memory and stays fairly stable for a while, then shifts when the program enters a new phase (a different loop, a new data structure). The key rule of thumb is simple: if the OS keeps each process's working set resident in physical frames, page faults stay rare and the program runs smoothly. If the combined working sets of all running processes exceed available frames, the system cannot keep them resident and starts thrashing — constantly evicting pages it is about to need again.

Why it matters: the working-set idea explains both why demand paging works (you only need the hot pages resident, not the whole program) and where it breaks down (thrashing, when working sets overflow memory). It guides the OS in deciding how many frames to grant each process and which to evict (replacement policies like least-recently-used approximate 'keep the working set'). The honest framing: virtual memory's good performance is not magic — it rests entirely on the empirical fact that real programs have working sets. Defeat that locality and the illusion gets expensive fast.