In this project you will required to implement the "Working Set" scheme and three page-replacement 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.
You may want to refer back to the Introduction to Nachos for some details on the memory system in Nachos.
The working set describes the number of pages of physical memory allocated to a process. To prevent a process from "thrashing", a record is kept of which pages are accessed during a fixed interval. This record is then used to calculate membership in the working set.
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. In this way, the length of a bit field directly determines the amount of history it can keep. The number of history bits (or the amount of memory) is referred to as the "Delta".
The history field for a page table entry with a Delta of 8 is shown below. Note that at times t1, t3, and t7 the page is accessed. This information is shifted once to the right at each time interval and, by t9, the first access is "forgotten".
One way to implement the working set 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.
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 most significant bit of the history field to indicate an access occurred. 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.
At the end of each processes' quantum (i.e. when the process is preparing to be context-switched out in Thread::Yield), you need to calculate the working set size for the process. This is done by counting all of the pages the process has accessed in the last Delta intervals. You should store the working set size and use it to determine when a process is using too many physical pages. 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 working set size to 4 pages and the maximum working set size to 30 pages. This will ensure that no process is forced to use too few pages or is allowed to use too many pages at once.
Next, the history bits for that process should be aged by shifting them to the right one position. In C, you can use the >> operator to shift an integer to the right (eg. 8 >> 1 = 4). This allows the process to slowly "forget" old accesses.
To discard a page, information contained in the bit field can be used to implement several replacement algorithms (i.e. LRU, FIFO, etc). The function MemoryManager::Choose_Victim is 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 we have provided stubs for in userprog/addrspace.cc.
In this project you will be required to implement a working set concept in nachos as described above. The size of the Delta history field will be varied for testing. Values will be 1, 2, 4, and 8 bits. You will also be required to implement 3 page replacement algorithms to be used in conjunction with the working set implementation. For this project you will be required to implement LRU Approximation, FIFO, and Enhanced Second Chance (see Silberschatz & Galvin, Chapter 9 for details).
You will be required to test the page-fault rate and number of pages outs of your implementation. For each page replacement algorithm, you should run it with each of the 4 Delta values on the 2 user programs we have provided (access1 and access2) and gather the number of page faults and page outs that occur. This will give you 8 data points for each algorithm. You should make two graphs plotting the number of page faults and page outs against the delta values used: one with the data for all of the algorithms and Delta values for the access1 user program and another for the access2 user program. Each graph should have six lines on it: one line for each algorithm for page faults and one line for each algorithm for page outs. The data points for each algorithm should be connected.
The performance data gathered should be neatly graphed. Brief discussion and explanation of results should be presented. In particular, give reasons that the given test programs performed as they did against the various replacement algorithms and the Delta sizes.
To do this project you should download a new version of the Nachos source (so that the orignal scheduling code is used). This version implements several new command line options to help you with your testing as well as per-process statistics.
To facilitate testing of your page replacement algorithms, you may want to use these a command line options to Nachos:
In the first line, the number in brackets is the PID of the process. The other three numbers on the first line are the total number of ticks the process used, the number of user ticks it used, and the number of system ticks (i.e. in the kernel) it used. The second line shows the number of context switches, broken down into voluntary and involuntary context switches. An involuntary context switch is one caused by the quantum expiring (whereas a voluntary context switch is caused by the process moving to a non-READY state such as BLOCKED.) The last line shows the number of Console reads and writes, the number of paging faults, and the number of page-in and page-out operations.
At this point, only the dummy 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.
You must test all combinations of you algorithms on the test programs supplied:
This makes a total of 24 tests. In order to facilitate running these tests, we have created a script called run-nachos-tests that will automate the testing process. To use it, you must be in the nachos/test directory (the script itself is also located in that directory). While running, it will print information about what tests it is running. At the same time, it saves all of the output of the tests to a file called results in the same directory. Here is the procedure for running the tests:
When the tests finish running, examine the results file it created. You should see the output of all 24 tests in the file. Make sure there are no errors that caused a test to fail. These are the results that you must include with your final report as well as plot on a graph.
You will need to keep track of information on a per-virtual page basis. In Nachos, this will mean making modifications to the TranslationEntry to keep track of new data. Some of the information you may need is listed below.
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 ClearPageSC, 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 the thread's quantum expires (in Thread::Yield), you need to calculate the new working set size and 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.
As with the previous Nachos projects, the amount of code to be written is not very large but it requires a great deal of thought. If you find yourself writing much more than 100 lines of new code, you need to rethink what you're doing and how you're doing it. This means you need to start thinking about this project early.
A set of empty functions have been provided 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.
The other stub routine you must fill in is AddrSpace::TooManyPages. This routine must decide if the process is already using all of its allotted working set.
Files that you will need to reference or modify include:
As a team, turn in the following items (as before):
As an individual team member, send email to the cse451 account on CSE, cse451@cse.unl.edu, and report the contribution of each team member as a percent of 100. Please include the name, login of each team member, and percent of contribution in your mail message. The subject should be PA6. Your score may be modified based on your individual contribution. A large descrepency between the reports sent by team members will require a team meeting with the instructor.
Grading will be divided among the parts of the project as follows:
Program Listing
Works Correctly 50%
In-line Documentation 15%
Quality of Design 15%
Design Document 15%
Testing 5%
Choose a team member's login for use with the handin program. In addition to turning in your code with the handin program, please include a README file that includes your name(s), email address(es), and login ids.