Assignment 6: Page Replacement with the Clock Algorithm

Assignment 6: Page Replacement with the Clock Algorithm

In this assignment you will extend your work on Project 5 to include page replacement, so MCryptFiles can be larger than the available physical memory. The learning goal for this assignment is to for you to learn about page replacement in general, and about the Clock Algorithm in particular.

Getting Started

To get started on this assignment, login to the myth cluster and clone the starter repo with this command:

git clone /afs/ir/class/archive/cs/cs111/cs111.1236/repos/assign6/$USER assign6

This will create a new directory assign6 in your current directory and it will clone a Git starter repository into that directory. This assignment builds on Assignment 5, so once you've cloned the starter repo, cd into the assign6 directory and invoke the following command:

make copy_mcryptfile_sources

This will copy your code from Assignment 5 into the assign6 directory so that you can use it for this assignment. The command assumes that your work for Assignment 5 is in a directory named assign5 with the same parent directory as assign6. If this isn't the case, the command above will fail; ask for help on Ed if that happens. If you didn't get Assignment 5 fully working, you may need to keep working on it in order to complete this assignment. For this assignment you will write additional code in mcryptfile.hh and mcryptfile.cc to implement page replacement with the Clock Algorithm.

As always, the directory contains a Makefile; if you type make, it will compile your code for both problems together with a test program test.cc, producing an executable file test. You can invoke ./test with an argument giving the name of a test to run (invoke it with no arguments to see a list of available tests). You can also invoke the command tools/sanitycheck to run a series of basic tests on your solution. Try this now: the starter code should compile but almost all the tests will fail.

The Clock Algorithm

The APIs for MCryptFile will not change for this assignment, but you may no longer assume that there are enough physical pages to accommodate all of the pages in all of the open MCryptFiles. If a page fault occurs when all of the available physical pages are in use, then the Clock Algorithm must be used to choose a page to evict from memory.

Here is how the Clock Algorithm should work:

  • Each invocation of the Clock Algorithm returns a page to evict from physical memory. The goal is to choose a page that has not been referenced recently.
  • The algorithm maintains a clock hand that selects a particular page of physical memory (PPage). Initially it refers to the first page (lowest Ppage address).
  • When the algorithm is invoked, it advances the hand to the next PPage. It then checks to see whether that PPage has been referenced since the last time the hand pointed to this page. If not, select that page for replacement: write it back to its file if it's dirty, then unmap the page from its current VMRegion.
  • If the page at the clock hand has been referenced, then mark the page as not referenced, advance the clock hand and check the next PPage; repeat this until a page is found for replacement.
  • When the clock hand reaches the end of physical memory, then it wraps back to the beginning.
  • The Clock Algorithm described in lecture assumes the availability of "referenced" bits for each page, set in hardware. For this assignment, we don't have access to the hardware bits. However, you can use page protection to compute this information, using an approach similar to the way you tracked dirty pages in Project 5. Maintain referenced information in your supplemental page map.
  • In lecture, it was mentioned that some systems consider whether a page is dirty when deciding whether to evict it (a dirty page gets an "extra chance" in the algorithm). For this aassignment we won't do that: the decision to evict should be based on the referenced bit alone. Of course, writing a page should set the referenced bit.

Reverse Page Map

For this assignment you will need to keep track of which VPage corresponds to each PPage (if any). You should be able to do this with a std::vector with one entry for each PPage (we'll leave the details of this design to you). This structure is called a reverse page map. Note that PhysMem::npages() returns the total number of pages in the pool, and you can assume that all of the PPages have adjacent addresses. PhysMem::pool_base() returns the first PPage; you can compute PPages for other pages by adding multiples of the page size to the this value.

Global Replacement

You should implement global replacement: all pages from all MCryptFiles are in a single pool. Thus, a page fault on one MCryptFile could evict a page from another MCryptFile.

Suggested Implementation Order

  1. If you didn't implement the supplemental page map as a static variable in Project 5, make it static now. Otherwise you'll run into problems when implementing eviction.

  2. Implement the reverse page map.

  3. Modify your page fault handler to implement FIFO replacement when memory is full: starting with the first page in physical memory, each fault replaces the next page in circular order. Once you do this, the big_file test should pass.

  4. Modify your page fault handler to emulate the referenced bit as well as the dirty bit.

  5. Implement the Clock Algorithm in mcryptfile.cc and use it to evict a page when a page fault occurs and there are no free pages. All of the tests should now pass.

One of the challenges of this assignment is to make sure that the supplemental page map, the VMRegion's page map, and the reverse page map are always consistent with each other. When you update one, be sure to update the others to match. For example, if you set the protections for a page to PROT_READ in the supplemental page map, you must also call VMRegion::map on the page with PROT_READ. Inconsistencies among these structures are one of the most common sources of bugs.

Submitting Your Work

Once you are finished working and have saved all your changes, submit by running tools/submit.

We recommend you do a trial submission in advance of the deadline to allow time to work through any snags. You may submit as many times as you like; we will grade the latest submission. Submitting a stable but unpolished/unfinished version is like an insurance policy. If the unexpected happens and you miss the deadline to submit your final version, the earlier submit will earn points. Without a submission, we cannot grade your work. You can confirm the timestamp of your latest submission in your course gradebook.

Grading

Here is a recap of the work that will be graded on this assignment:

  • mcryptfile.hh and mcryptfile.cc: add enough functionality, including a reverse page map, to implement the Clock Algorithm for page replacement.

We will grade your code using the provided sanity check tests and possible additional autograder tests. We will also review your code for style and complexity. Check out our course style guide for tips and guidelines for writing code with good style!