An operating-system process's working set is the set of distinct memory pages used in a declared recent window. Here the window counts memory references, not clock time: let identify the memory page accessed by the th memory reference, and let the positive integer be the window length. Immediately after reference ,
Repeated memory references to the same memory page contribute only one set element. The working set size is the cardinality . This recent footprint estimates current demand; it cannot guarantee which memory pages future memory references will need. The resident set instead records which memory pages are actually present in computer memory.
For the 20-reference sequence in memory thrashing and , the successive working sets begin , , and . At , the window is references 2–5, namely , so again. Every later four-reference window contains all four memory pages. Under three-page frame LRU replacement, however, the resident set at is : page 2 was evicted. Consequently the working set size is four even though only three memory pages are resident. Under four-page frame LRU replacement, the resident set contains the complete working set after reference 4.
Figure 1.
A four-reference working set remains four pages while a three-frame resident set contains only three
. Details.
Window choice matters: on this same sequence, reports only two distinct memory pages after reference 2, despite the recurring four-page cycle. A short window forgets useful memory pages sooner; a long window retains evidence from older phases. Enlarging the window can only enlarge or preserve the working set at fixed , because the shorter window is contained in the longer one. No single window is best for every workload.
For a concrete multiprogramming budget, suppose three operating-system processes each have a four-page working set, no shared page frames, and only eight page frames are available for their data. Their combined demand is 12 page frames; all three working sets cannot be resident together. Letting two operating-system processes run while the third waits makes their eight-page demand fit in this simplified model. Real budgets also reserve computer memory for the operating system and other uses; shared memory pages must not be counted repeatedly as different physical copies.
Peter J. Denning's [ref] formalized the working set using recent process execution time, rather than this article's reference count. Its central insight connected memory demand to process scheduling: deciding which operating-system processes run also decides which working sets need room. Temporal locality makes recent use informative, without making it a promise about the future. The beautiful distinction is between a large possible address space and the smaller footprint of the current activity.

Articles by others on the same topic (NaN)

There are currently no matching articles.