Secondary Page Caches

When selecting a page for removal from a process working set, it would be helpful to select a page that would not be needed soon. When the data contained on that page are referenced again, yet another page fault is needed to bring it back into the working set, increasing overhead.

Unfortunately, it is not possible to predict with any real accuracy which pages should be removed from a working set to best reduce the number of future page faults. Attempts to analyze paging behavior can introduce even more overhead than they avoid.

OpenVMS attempts to solve the page-selection problem by providing an environment in which the consequences of a bad choice are held to a minimum. OpenVMS makes no attempt to select a page for removal intelligently; a heavily used page may be faulted out, only to be faulted back in shortly. A seldom-used page is equally likely to be faulted out, but won't come back as soon.

As a process executes programs, a pattern sometimes emerges. A program will often generate a flurry of page faults at its start and then concentrate mainly on a certain set of pages for a longer period of time. Eventually, so long as the required number of pages can fit in the working set, the extraneous pages will naturally get removed, leaving only the frequently accessed pages.

OpenVMS provides two special caches to reduce the performance degradation caused while the population of the working set is sorting itself out. The free page list and the modified page list serve as secondary page caches, reducing the damage done by indiscriminate page removal.

When a page is removed from the working set of a process, it is placed on the free page list (if it has backing store or is no longer needed) or on the modified page list (if no backing store exists and the page is still needed). When a page is placed on the free page list or modified page list, its contents are not immediately destroyed.

This means that when a page is removed from a working set, it remains available in physical memory for some time. If a page fault is generated while the contents of the target page are still valid, the page can simply be moved from the free or modified list back into the process working set. Therefore, heavily used pages removed from a process working set stand a good chance of being retained in memory until they are referenced again.

Of course, other processes continue to allocate pages from the head of the free page list for various purposes. Pages not faulted back into a working set will eventually be erased as they come to the head of the free page list.

When a page fault can be resolved from the free or modified page list, it is known as a soft fault, whereas faults that must be resolved from backing store are called hard faults. Soft faults can be serviced many times faster than hard faults. The ratio varies according to processor and disk speed, but a ratio of 100:1 is traditionally accepted.

Applications that make poor use of memory resources might rely (intentionally or not) on the secondary page caches to increase their performance. However, since all processes share these page caches, they cannot be relied on to make the application perform well, particularly on a heavily loaded system. This also implies that the poorly written application can adversely affect all other processes. The programmer remains responsible for making careful use of system resources.