13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

102 Space Management Chapter 3entirely swapped out to keep the multiprogramming level low are kept on a mainstorewait list in the medium-term scheduler. After a while, these processes areallowed to execute again, perhaps at the expense of other processes that are thenswapped out. The Hysteresis Principle tells us that once a process is swapped in orout, it should be left in or out for a significant length of time, in order to recoup thecost of swapping it.No amount of cleverness in choosing swaps can prevent thrashing by itself; reducing thelevel of multiprogramming is a necessary tool. However, reducing the multiprogramminglevel alone is not wise, since higher levels of multiprogramming tend to treat longand short jobs more fairly and allow more overlap of computing and transput.We will begin our study of page replacement by simplifying the problem. Later,we will return and introduce more complexities. To start with, let’s assume that one processis ready but that its virtual space is larger than physical store. When it needs a pagebrought in, one of its own pages must be discarded. We say the process is ‘‘pagingagainst itself.’’ Further, we will not try to be clever and bring in pages before they areactually referenced, nor will we swap out a page before we need its page frame. We willstick to pure demand paging, where all page traffic between main and backing store isbased on the demand generated by the process.To evaluate different policies, we will use a page-reference string, which is a listof all the pages referenced by the process in the order in which they are referenced. Forexample, a process with a virtual space of five pages, numbered 0 through 4, might havea page-reference string that starts as follows:0032312412212221100...The same page may be referenced two or more times in a row, and some pages might bereferenced very seldom or never. We will define each page-replacement policy bydescribing which page, if any, is swapped out for each reference in the page-referencestring. This decision will depend, of course, on how many page frames are available andwhat the reference string looks like.Actual reference strings have been deduced by attaching hardware probes to computerswhile processes execute. These reference strings do not have the behavior youmight expect, each page being equally likely to be referenced at any time. Instead, aphenomenon called locality is observed. At each instant in a program’s execution, a fewpages are in active use, and others are not in use at all. Locality is especially pronouncedin programs that use stacks and ones that scan arrays sequentially with small strides.As the pages in the active set change, we say that the program has gone through aphase change. Such a phase change is observed, for example, when a compiler finishesits first pass and begins the second.We will examine how various policies behave with respect to a synthesized pagereferencestring with 10,000 references selected from a virtual space of 100 pages.Details of how this string was generated can be found in the exercises at the end of thechapter. It is built to display locality of reference but not phase changes. In this pagereferencestring, only 71 of the 100 pages were actually referenced. This figure is notsurprising, since 10,000 references is actually quite short for a program of 100 pages.One way to present the behavior of a page-replacement policy is to show howmany faults it suffers with our synthesized page-reference string for different sizes ofphysical space, ranging from 1 to 100 page frames. These results are often shown in afault-rate graph, as shown in Figure 3.19.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!