An Operating Systems Vade Mecum

Page-replacement policies 115methods may take into account scheduling information, such as the process priority, inorder to avoid removing all the pages from an important process.Methods that maintain a pool of free page frames are called pool methods. A pagecan be added to the pool when it leaves the working set of its process. Alternatively, thestorage manager could continually place page frames in the pool, at a rate such that thebacking store is kept relatively busy. If this ‘‘background discard’’ algorithm is the solesource of free pages, thrashing is avoided because pages cannot be brought in faster thanthey are being swapped out.No matter how the pool is created, dirty pages in the pool can be ‘‘cleaned’’ bywriting them out to backing store whenever the backing store device is idle. Later, swappingout the page will be free. If a process accesses a page that is in the pool, it is notexpensive to place the page back into the virtual space of that process. The pool thus letsus resist swapping pages out, in keeping with the Hysteresis Principle. If a cleaned pageis removed from the pool and returned to a process, the cleaning has cost some effort, butwe hope not much.We noticed that shared segments warrant special treatment. Since sharing on thebasis of individual pages usually doesn’t make sense, segmentation is joined to paging toprovide sharing. Shared pages are then elements of segments that are entirely shared.Local methods don’t really make sense for a shared page because swapping it out has anon-local effect. Instead, the entire segment can be considered a swappable entity. If itis decided to swap it out, all its page frames are placed in the free pool, and cleaning isscheduled for the dirty ones.Pages that are tied down must not be swapped out. We have seen that pagesinvolved in transput must sometimes be tied down. If the pages of the kernel are subjectto swapping out, it must tie down those pages that hold the storage-manager programs forboth the policy and the mechanism of paging. Otherwise the kernel will suffer a pagefault from which it cannot recover. Also, some forms of real-time scheduling require thatpaging cost be avoided; an entire process may be tied down if it needs guaranteed serviceevery tenth of a second. Some operating systems provide a service call by which a processrequests that a segment be tied down. The scheduler might favor such a process,under the assumption that the more time that process receives, the sooner it will be willingto unlock the segment. This call should be used with discretion because it gives thecaller both a space and a time advantage over other processes in the ready list.Startup-phase conflicts.All the policies that control the level of multiprogrammingare subject to a phenomenon called startup-phase conflict. The startup phaseof a process is the period right after the scheduler has taken it from the main-store waitlist until the process has acquired its working set of pages. During this phase, the virtualclock of the process moves very slowly because page faults are so frequent. If manyprocesses are in startup phase simultaneously, they compete for access to the backingstore. Their virtual clocks therefore advance still more slowly. In extreme situations, theprocessor becomes underused, and every process in the ready list is in startup phase.Startup-phase conflict can be controlled by restricting the number of processesallowed to be in startup phase at one time. If there are too many such processes, newadditions to the ready list are delayed. The kernel can decide that a process is in thestartup phase by consulting its virtual clock. Any process whose virtual clock is less thanthe tunable parameter ‘‘startup-phase virtual duration’’ is considered in startup phase.