An Operating Systems Vade Mecum

Page-replacement policies 1111 type2 PageFrameTableEntry =3 record4 { All fields set by the storage manager }5 Free : Boolean; { true if unoccupied }6 Process : ProcessNumber; { which process owns this frame }7 VirtualPage : integer; { where in virtual store of that process }8 end;9 var10 PageFrameTable = array PageFrameNumber of PageFrameTableEntry;Processes that are in wait lists will lose all their pages after a while. Processes inthe ready list will compete for page frames. The number of pages any process managesto acquire will depend on how many it needs and how often the scheduler gives it achance to run. When a process is placed in the ready list after a long absence, it willencounter a page fault almost immediately. It will be slowed by page faults during thestartup period but will finally have its most heavily used pages in physical store and willbe able to make progress. However, the number of processes in the ready list may be sohigh that not one of them succeeds in swapping in an adequate number of pages. In thatcase, each ready process will make very little headway before the next page fault, andthrashing will set in.The next few policies try to prevent this catastrophe. They do so by restricting thelevel of multiprogramming.7.8 Working setThe storage manager can estimate which pages are currently needed by each process.This set is called the working set of that process. The working set policy restricts thenumber of processes on the ready queue so that physical store can accommodate all theworking sets of ready processes. Any other ready processes are placed in the main-storewait list, where they remain until the medium-term scheduler decides to exchange someof them for ready processes. (Refer to Figure 2.6 to see how the scheduling levels arearranged.) When such a process is brought back to the ready list, the pages in its workingset may be swapped back in before it starts running. These swaps are examples of prefetching,which is the opposite of demand paging.When the medium-term scheduler makes an exchange, the process that is movingto the main-store wait list loses all its pages; they are all marked as available for swapout. When a page must be swapped out, the best victim is a page that does not belong toany of the currently ready processes. If there is no such page, any of the previousmethods, preferably some form of NUR, may be applied in a global fashion.The working set for each process is defined as the pages that have been accessedby the process during the most recent w units of virtual time. Virtual time is a clockthat is maintained separately for each process. (Whenever a process is switched out, theamount of physical time it was given when it was running is added to the virtual time thatwas recorded in its context block. The virtual time of a process that is running is the virtualtime recorded in its context block plus the amount of physical time it has been running.)If the working-size parameter w is too small, the working set will not contain allthe pages that are really in use by the process. If w is too large, then as the program