EECS 678: Intro to Operating Systems Programming Assignment 3: Virtual Memory in Nachos

Transcription

1 EECS 678: Intro to Operating Systems Programming Assignment 3: Virtual Memory in Nachos 1. Introduction 2. Background 3. Assignment 4. Implementation Details 5. Implementation Overview 6. Testing and Validation 7. Sample Performance Data Table 8. A Few Quick Notes 9. Questions 10. Grading and Submission 1. Introduction In this project you are required to implement the "Working Set" scheme and three pagereplacement policies in the Nachos operating system as discussed in class (and in your book). You will then use your implementation to collect data describing the performance of these algorithms and answer a number of questions. As in PA2, you may do this assignment in groups of two. To be sure you start with the same Nachos archive as this project description assumes, please grab this assignment's starter code from the website. If you do not start with this TAR file to implement this project, I will not grade your project. You may want to refer back to the Nachos documentation on the website for some details on the memory system in Nachos. The lab on Tuesday, November 14 will also cover the memory system in Nachos. 2. Background: The Working Set The working set is the set of all virtual pages a process is actively using. To prevent a process from thrashing pages in and out, a record is kept of which pages are accessed during a fixed accounting interval. This access record is then used to calculate page membership in the working set and to determine how many physical pages should be granted to the process. Most systems for implementing a working set involve using a record of N intervals. Page accesses are "remembered" over time by setting bits in a bit field of a given length. As time proceeds, new data is shifted into the most significant bit (MSB) of the field and old data is shifted out periodically. In this way, the length of the bit field in the page table entry directly determines the amount of history it can keep about access to each page. The number of history bits (the number of accounting intervals) is referred to as the "Delta". The history field for a page table entry with a Delta of 8 is shown below. Note that during time periods t1, t3, and t7, the page is accessed. This information is shifted once to the right at the end of each time interval and, by period t9, the first access is "forgotten".

2 3. The Assignment and Implementation Details In this project you will be required to implement simple working set management policies in Nachos as described above. The size (Delta) of the page access history bit field will be varied, and you will perform tests to see how different sizes affect performance. Values will be 1, 2, 4, and 8 bits (and thus time periods). You will also be required to implement 3 page replacement (victim selection) algorithms to be used in conjunction with your working set implementation. For this project you will be required to implement FIFO (section in the text), LRU Approximation (this is the Record Reference Bit algorithm in the slides also known as the Additional-Reference-Bits Algorithm from section in the text), and Enhanced Second Chance (this is similar to the Second Chance algorithm discussed in class see section in the text for details). Implementation Details To differentiate between the two meanings of "working set" in the rest of this document, we will use the term "actual working set size" for the number of virtual pages a process has used in recent history and the term "prescribed working set size" for the number of physical pages the kernel has determined a process can be using. As will become evident below, both values will change throughout the execution of a process. One way to implement the working set schema is to introduce a bit-field into the page table entry (class TranslationEntry) for each page of a processes' virtual memory. For this project, you will need to keep a history of 8 intervals. Therefore, you can use an unsigned char to store your history. We have prepared some simple example code using C/C++ bit operations to help with the details. When a page is accessed by a program, the virtual address of the page is translated to a physical address by address translation logic (in Machine::Translate). This logic should be modified to record the page access in that page's history field. Since the data is moved from left to right, you should set the

3 most significant bit of the history field to indicate an access occurred during the current accounting interval. When a page is written to, TranslationEntry::dirty is set to true. This will indicate when a page is dirty and therefore needs to be written out to disk when it is paged out. This information is required by the Enhanced Second Chance algorithm. We will compare the size of the actual working set to the number of physical pages the process owns. When the process owns more physical pages (a.k.a. "frames") than it is actually using, we will take away some of its unused physical pages so that they can be better utilized by other processes in the system. We can achieve this repossession of unused pages by periodically inquiring how many pages the process is actively using and, with that number, constraining the process's address space size by setting the prescribed working set size for the near future of the process's execution. In this way, a process's actual working set size can grow at any rate (based on which virtual pages it accesses), but it will never own more physical frames than its prescribed working set size at a given time. A related implementation is specified in the next paragraph. Each time the scheduling interrupt expires (i.e. each quantum), we increment and test a counter associated with the current thread. When this counter expires, it is reset and the Thread::refreshWss() member function is invoked for the current thread. You need to fill in this stub in order to calculate the actual working set size for the process. This is done by counting the number of pages the process has accessed in the last Delta measurement intervals using the access bit fields in the page table entry for each page. The prescribed working set size will be set to this actual working set size and will remain at that number until the next call to Thread::refreshWss(). Until that point, it will be used to determine when a process is using too many physical pages (as discussed above). Since the history is shifted from left to right, information on the most recent interval is contained in the most significant bit. You can use an AND operation to look at only the top Delta bits as follows: Delta Mask Example 1 0x80 history & 0x80 2 0xC0 history & 0xC0 4 0xF0 history & 0xF0 8 0xFF history & 0xFF You should make the minimum prescribed working set size of a process 4 pages and the maximum prescribed working set size 32 pages. This will ensure that no process is forced to use fewer than a minimally feasible number of frames or is allowed to use too many frames at once. The lower limit of 4 is fairly easy to see. The upper limit of 32 is quite arbitrary, and would normally depend on the nature of the application programs. If the process is using too many frames, the extra pages should be paged out immediately. Selecting which pages to page out relies on the page replacement policy, as explained below. When selecting a page to page out, information contained in the access history bit fields of all the virtual pages currently mapped to physical pages can be used to implement several replacement algorithms (i.e. LRU Approximation, FIFO, etc). The function MemoryManager::Choose_Victim is

4 called whenever a page needs to be paged out. This function determines which page-replacement policy is being used and calls the appropriate function in the AddrSpace object (AddrSpace::FIFO_Choose_Victim, AddrSpace::LRU_Choose_Victim, or AddrSpace::SC_Choose_Victim). You need to implement these policies by filling in the functions for which we have provided stubs in userprog/addrspace.cc. Every time a process' working set size is refreshed, the history bits for that process's address space should also be aged by shifting them to the right one position. In C, you can use the >> operator to shift an integer to the right (e.g. 0x8 >> 1 == 0x4). This allows the process to slowly "forget" old accesses. Each time a thread runs for 10 quanta, the handout code will cause Nachos to invoke Thread::refreshWss() for the current thread. Just to be absolutely clear, that function should: 1. Calculate the new prescribed working set size (which is just the actual working set size at the moment). 2. Make certain that the thread does not own more frames than its new prescribed working set size allows (e.g. consider the scenario where step 1 actually calculates a smaller number than the prescribed working set size was before); we call this the contract step. 3. Shift the reference history associated with each virtual page in the thread's address space. The selection of 10 quanta as the period was rather arbitrary. In our testing, we have found that it tends to reveal the type of trends we want you to discover, but there is nothing more complex than that behind the choice. Other values might work better. This project used to refresh the prescribed working set size on every quantum, but that frequency seemed to be too restrictive because it was rather difficult for a program to reference very many pages in a period only 8 quanta long (which is the most history a thread could have: delta = 8). Now delta = 8 corresponds to a history window of 80 quanta, in which a thread can reference many more pages, providing a far richer view of what pages are being used. Realize that the sampling period can also be too long, so any period's effectiveness can be evaluated only with respect to program behavior being measured. NOTE: By default the contract step is disabled. You still need to implement this step, but the trends we wish you to recognize are less obvious when contraction is enabled. Therefore, when you answer the questions, you will disable contraction. Implementation Overview Think of this section as a quick overview of everything you will need to implement as described in the above section. You will need to keep track of information on a per-virtual page basis. In Nachos, this will mean making modifications to the TranslationEntry class to keep track of your new data. You will need new fields for the following: Reference History - Set the MS bit during a reference and shift to the right after each access accounting quantum as discussed above. Load Time - Update with the current clock cycle (this is the time stamp counter on a Pentiumclass CPU) when the page is loaded into memory. NOTE: The calls are already in place to set this value when appropriate. You only need to fill in the stub functions listed below. NOTE: The fields you need for the enhanced second chance algorithm (i.e. when a page is referenced, and whether or not it has been written to) have already been initialized and are already being updated

5 properly. Also, if you implement the Reference History field correctly, you do not need to introduce any other fields to implement the LRU policy correctly. Once you have added new fields to the TranslationEntry, you need to properly update these values. First, you will need to implement the body of the clearrefhistory, settime, and gettime functions, which should properly initialize your page statistics. Second, you will need to implement updates to your access fields in the function Machine::Translate. Every time a thread refreshes its prescribed working set size (in Thread::refreshWss), you need to calculate the new prescribed working set size, trim down the process's owned frames to match the newly calculated prescribed working set size by paging out some pages if necessary, and then shift the history information. Finally, you need to implement the body of the stub functions (in userprog/addrspace.cc) which will actually choose a victim page to be swapped out based on your new data fields. The stub routines are listed in the next section. Stub Routines We have provided a set of empty functions which are called at appropriate places in the code for proper operation. These are listed below. You will need to modify them to work with your code. userprog/addrspace.cc These stub routines should select a physical page based on the named algorithm. See the comments in the code for more detail. SC_Choose_Victim LRU_Choose_Victim FIFO_Choose_Victim The other stub routine you must fill in is AddrSpace::TooManyFrames. This routine must decide if the process owns more frames than its prescribed working set allows. TranslationEntry::clearRefHistory This should reset your reference history information to values appropriate when the page is first loaded into memory. TranslationEntry::setTime This should set the time information to the value specified. TranslationEntry::getTime This should return the time information for the page. Important Files Files that you will need to reference or modify include: userprog/addrspace.h - Contains the definition of Address Spaces userprog/addrspace.cc - Contains the implementation of Address Spaces machine/translate.h - Contains the definition of the virtual to physical address translation routines machine/translate.cc - Contains the implementation of the virtual to physical address translation routines threads/thread.h - Contains the definition of the Thread Class threads/thread.cc - Contains the implementation of the Thread Class, including the Thread::refreshWss routine. threads/system.h - Contains the definitions of the variables wsdeltasize and pagereplpolicy which you must use in your algorithms. threads/system.cc - Sets the variables wsdeltasize and pagereplpolicy which you must use in your algorithms.

6 userprog/memmgr.h - Contains the definition of the Memory Manager userprog/memmgr.cc - Contains the implementation of the Memory Manager, including ChooseVictim - the main page replacement dispatch algorithm. userprog/swapmgr.h - Contains the definition of the Swap Manager userprog/swapmgr.cc - Contains the implementation of the Swap Manager userprog/bitmap.h - Contains the definition of a bit map userprog/bitmap.cc - Contains the implementation of a bit map Disclaimer As with the previous Nachos projects, the amount of code to be written is not very large but it requires a significant amount of thought. If you find yourself writing much more than 200 lines of new code, you probably need to rethink what you're doing and how you're doing it. This means you need to start thinking about this project early (i.e. NOW). 6. Testing and Validation The most obvious performance metric for page replacement and working set management algorithms is the page fault frequency, which we gather using histograms. We will also use the total number of page faults experienced by a program during its execution and also gather the number of page-outs. Recall that a given approach will work better for some access patterns than others. We provide four user programs for this assignment which exhibit different memory access patterns and which thus exercise the page replacement and working set management algorithms in different ways. For each page replacement algorithm, you should gather data for each of the 4 Delta values on the 4 user programs we have provided (access1 through access4) and gather the number of page faults and page outs that occur. This data gathering step has been automated for you by the make regress make target in the nachos/dsui-vm/page_replacement_policy directory. It is invoked like this: "make regress". It must be ran from within the nachos/dsui-vm/page_replacement_policy directory. When it completes running its tests (which takes a few minutes) the data collected may be analyzed for statistics and used to generate histograms showing the number of machine ticks between page faults. Example run of "make regress" (actual parameters have been shortened here): > cd nachos/dsui-vm/page_replacement_policy > make regress Starting subprocess:../userprog/nachos -S swapfile_fifo_1_access1 -prp fifo -delta 1 -x access1 Starting subprocess:../userprog/nachos -S swapfile_fifo_2_access1 -prp fifo -delta 2 -x access1 Starting subprocess:../userprog/nachos -S swapfile_fifo_4_access1 -prp fifo -delta 4 -x access1 Starting subprocess:../userprog/nachos -S swapfile_fifo_8_access1 -prp fifo -delta 8 -x access1... others for lru, secondchance, access1-4, etc....

7 After the tests have ran there are two types of post-processing that can be done. The first is to generate a table, listing for each combination of program, page replacement policy, and delta, the number of page faults versus page outs. The second is to generate histograms showing the number of ticks between page faults. But before either the table or histograms can be generated we must post-process the data collected. Post-Process Testing Data > cd nachos/dsui-vm/page_replacement_policy > make postprocess This step will analyze the data collected from running make regress and prepare data for display and conversion into histograms. This step must be preformed before generating the table or histograms, and it takes several minutes (I recommend using cycle4 if you're using the cycle servers). Generate Page Fault Stats Table (form: Page Faults / Page Outs) > cd nachos/dsui-vm/page_replacement_policy > make table The performance data table will be sent to standard out and must be included in your report. If this fails, it is probably because instances of post-processing are still finishing. Just wait a few seconds (or check what is running with `ps aux`). Generate Histograms > cd nachos/dsui-vm/page_replacement_policy > make histos The generated histograms will be found in the dsui-vm/page_replacement_policy/pdfs directory New Command Line Options for Nachos The commands above will test each user program for each possible page replacement policy and delta value, but in order to facilitate testing of your individual page replacement algorithms with different delta values, we have added a few new command line options to Nachos. -prp <page-replacement policy> = allows you to select the page-replacement policy to be used by the system. There are four policies available: 1. dumb - Dummy algorithm 2. fifo - First-In First-Out 3. lru - LRU approximation 4. secondchance - Enhanced Second Chance At this point, only the dumb algorithm works. You must implement the code for the other algorithms. This value is stored in the variable pagereplpolicy. Its value is tested in MemoryManager::ChooseVictim to select the right algorithm. -delta <delta size> = allows you to set the Delta size for the actual working set calculations. This should be either 1, 2, 4, or 8. The default value is 1. This value is stored in the global variable wsdeltasize. You must use this value in your algorithms to maintain the working sets.

8 7. Sample Table A correct implementation will yield the following performance data table. See the explanation on the next page for how to interpret this. Program = access1: delta=1 delta=2 delta=4 delta=8 dumb 1640/ / / /1079 fifo 1641/ / / /1079 lru 1027/ / / /1011 secondchance 1027/ / / /1011 Program = access2: delta=1 delta=2 delta=4 delta=8 dumb 35977/ / / /33808 fifo 35978/ / / /33808 lru 32813/ / / /32753 secondchance 32771/ / / /32739 Program = access3: delta=1 delta=2 delta=4 delta=8 dumb 17/8 16/7 14/4 14/1 fifo 19/9 16/7 16/4 13/0 lru 13/7 13/6 13/3 13/0 secondchance 13/7 13/6 13/3 13/0 Program = access4: delta=1 delta=2 delta=4 delta=8 dumb 161/ /112 53/36 14/1 fifo 163/ / /104 13/0 lru 103/97 103/96 103/93 13/0 secondchance 103/97 103/96 103/93 13/0 Performance Table Interpretation The number on the left is the number of page faults for each run and the number on the right is the number of page outs. A perfect implementation will match exactly, but minor discrepancies are likely small errors and will not lose many points. The important thing is that the data in your table show similar trends. If the table produced by your implementation never matches these numbers, feel free to use this table to answer the questions below as opposed to the table produced by your implementation.

9 8. A Few Quick Notes Before proceeding, I have a few notes on the tests you have run or will run and the terminology used in the Nachos output and the questions below. Page Fault vs. Page In vs. Page Out A page fault occurs when a process has to access memory that is not already in its working set. A page in is essentially the same thing, but Nachos does not count the initial page in of the process' first page of program text and its last page of address space (i.e. its stack) as page faults. Thus, there will always be two more page ins than page faults. When answering the questions below, you may ignore these initial page ins (i.e. do not count them as page faults as Nachos does). A page out occurs when a process attempts to page in a page when its working set is full, and thus, must choose a victim to page out of its own working set. Startup and Exit Page Faults When Nachos starts a process, there are always two page faults as it works itself through the library code to the main program function. Similarly, there are always two page faults when a process navigates the code to exit a process. These are reported by Nachos as page faults, but you may ignore these four page faults when answering the following questions. The Contraction Step The code, as handed out, does not actually do the contraction step: it won't ever take frames away from a thread. This is contrary to the background information regarding the Working Set Scheme. When contraction is enabled, the trends we wish you to find are less obvious; thus, we've disabled contraction by default. This is what the wsscontractionenabled variable is for. That variable is sensitive to a command line switch to Nachos: "cwss". If the switch is present on the command line, then contraction ought to take place. For answering these questions, do not enable contraction. Please do try running tests with contraction enabled to see the difference; to do so, open dsui-vm/page_replacement_policy/prp_tests.py and add the "-cwss" option to the arg_list variable on line 66. The Big Picture As mentioned before, the code refreshes the working set size after every 10 quanta. Growth in the working set size is a consequence of the history of page reference: more referenced pages means a bigger working set size. Note that as delta increases, the amount of available history also increases. Because the history is used to determine the working set size, greater delta sizes yield greater working set sizes. Our Test Programs access1,2,3 and 4 are simple memory loads designed to stress the PRP algorithms in predictable ways. access1 and access2 are the Row-major and Col-major access orders on the 1024 page array. access3 is Row-major on a 10 page array and access4 is 10 iterations of access3.

10 9. Questions For your final report, you must answer the following questions: 1. What is the absolute fewest possible number of page faults for access1 in Nachos? Note that the compiler stores its arrays in row-major order (see the note in access1.c) and that Nachos employs demand paging. What about for access3? 2. What is the absolute fewest possible number of page faults for access2 in Nachos? Note that the difference between access1 and access2 is the pattern in which they traverse the array. 3. Why does delta affect access1 page fault count for FIFO and DUMB but not for LRU and Enhanced Second Chance? 4. Look at the inter-page fault histogram for access1 with a delta of 8 for all the PRPs. All of the generated histograms are located in dsui-vm/page_replacement_policy/pdfs directory (the.histo files are located in dsui-vm/page_replacement_policy/histos). See the Testing and Validation section for how to create the histograms. There ought to be a main spike which all PRPs share. Explain the existence of that spike: to what does it correspond? This is a similar question to guide what we are looking for on question 4: SampleQ: Look at the histogram for access2 with a delta of 8 with Enhanced Second Chance. There ought to be one significant spike and another much smaller spike located at a larger tick count which all PRPs share (open the.histo file with a text editor; note that the minimum and maximum values for empty buckets ought to be ignored). Explain the existence of those two spikes: to what do they correspond? SampleA: For access2, there is a page fault for each iteration of the inner loop. The spike at the lesser tick count corresponds to the number of instructions between memory writes in the inner loop: it takes about 24 ticks for the inner loop body to write a value, increment the loop counter, check the loop condition, compute the next element's address, and then write to it. The other spike corresponds to when the outer loop is also incremented/tested between writes. Together they add up to = 32768, the number of data page faults. The big spike is 1024 times bigger than the small spike, because the inner loop happens that many more times than does the outer. 5. Now consider page-outs and three major influences: 1) PRP, 2) delta size => working set size, and 3) the program's memory access pattern. Consider 3) as you answer these two questions: For 1), in which programs did the PRP not really affect the page-outs, and give a reasonable reason for that. For 2), in which programs did the delta size have an effect? Where did it not? Why?

11 10.Grading and Submission For this project, you should turn in the following items: 1. The source tree you modified with a root directory named using your KUIDs bundeled into a TAR file and ed to me (mikejant@ku.edu). 2. A project report. This report should contain: 1. Discussion of design. Explain the reasoning behind the implementation you have coded. 2. Brief discussion of how you tested and debugged your implementation. 3. Brief explanation of the table of results from make table. Mention the different kind of memory access patterns exemplified by each program, why the page replacement algorithms handle each pattern as they do, and how (and why) the delta values affect the results. 4. Answers to the questions in section 9. Grading will be divided as follows: Approach Works Correctly 70% Design and Results Doc 10% Questions 20% Good luck. And please start early. This project is significantly more difficult than the previous assignments.