Due: Friday, December 8 at 11:59pm (No time for extensions)
The last project! In project 2, each process had a page table that was initialized with physical pages and their contents when the process was created. In project 3, you will implement a more sophisticated memory management system where physical pages are allocated on demand and pages that cannot fit in physical memory will be stored on disk.
You will implement and debug virtual memory in two main steps. First, you will implement demand paging using page faults to dynamically initialize process virtual pages on demand, rather than initializing page frames for each process in advance at exec time as you did in project 2. Next, you will implement page replacement, enabling your kernel to evict a virtual page from memory to free up a physical page frame to satisfy a page fault. Demand paging and page replacement together allow your kernel to "overbook" memory by executing more processes than would fit in machine memory at any one time, using page faults to multiplex the available physical page frames among the larger number of process virtual pages. When implemented correctly, virtual memory is undetectable to user programs unless they monitor their own performance.
You project will implement the following functionality:
The changes you make to Nachos will be in these two files in the vm directory:
These classes inherit from UserKernel and UserProcess. While the VM versions of these classes will be able to depend upon functionality in the base classes, the focus in this project will be on demand-paged virtual memory. As a result, you will be implementing new versions of key methods in VMProcess such as loadSections, readVirtualMemory, and writeVirtualMemory.
You will compile and run the project in the proj3 directory. Unlike the first two projects, you will not need to learn any new Nachos modules and will continue to use functionality that you became familiar with in project 2. Before starting your implementation, also see the Tips section below.
Central to this project are the following design aspects:
Most of the effort for this project is in parts 1 and 2. Parts 3 and 4 are very specific optimizations to improve the performance of paging.
1. (30%) Implement demand paging. In this first part, you will continue to preallocate a physical page frame for each virtual page of each newly created process at exec time, just as in project 2. And as before, for now continue to return an error from the exec system call if there are not enough free page frames to hold the process' new address space. The only special bit in TranslationEntries that you need to use for this part is the valid bit. You will not yet need to implement the swap file, page replacement, an inverted page table, etc. Instead, you just need to make the following changes:
Once you have paged in the faulted page, mark the TranslationEntry as valid. Then let the machine restart execution of the user program at the faulting instruction: return from the exception, but do not increment the PC (as is done when handling a system call) so that the machine will re-execute the faulting instruction. If you set up the page (by initializing it) and page table (by setting the valid bit) correctly, then the instruction will execute correctly and the process will continue on its way, none the wiser.
Testing: As long as there is enough physical memory to fully load a program, then you should be able to use test programs from project 2 to test this part of project 3. See the tips in the Testing section below for how you can control (increase or decrease) the number of physical pages (e.g., write10 is going to need more than the default of 16 pages). If you give Nachos enough physical pages, you can even run the swap4 and swap5 tests (and these tests do not use any system calls other than exit).
2. (58%) Now implement demand paged virtual memory with page replacement. In this second part, not only do you delay initializing pages, but now you delay the allocation of physical page frames until a process actually references a virtual page that is not already loaded in memory.
You can get the above two changes working without having page replacement implemented for the case where you run a single program that does not consume all of physical memory. Before moving on be sure that the two changes above work for a single program that fits into memory.
Now implement page replacement to free up a physical page frame to handle page faults:
After getting paging with multiple processes working with the memory tests and you then move on to readVirtualMemory and writeVirtualMemory, you should use the same lock to protect each page accessed in their while loops (e.g., so that between the time rVM brings a page into memory and you use arrayCopy on that page, the page is not chosen by another process for eviction).
As you implement the above operations, keep the following points in mind:
Testing: Start with the memory focused tests such as swap4 and swap5, and vary the amount of physical memory in Nachos to control how much demand paging each test must do. See the Testing section below for how to control the number of pages in physical memory.
3. (5%) In part 2, when evicting pages we ignored the dirty bit, i.e., we ignored whether or not the process had modified the page once it was brought into memory. As a result, when evicting a page we always wrote it to the swap file. In this part you will optimize page replacement by using the dirty bit. Consider a page P that has been written to the swap file and then read back into physical memory on a page fault. If P is again chosen for eviction, your implementation will only write P back to the swap file if P has been modified (i.e., if the dirty bit is true in its TranslationEntry). If P is not dirty, then it does not need to be written to swap since the version of P in memory is the same as the one in the swap file. Note that (1) this also means that you should not free up a page in the swap file for a given virtual page until the process terminates, and (2) you will need to modify writeVirtualMemory to set the dirty bit on the page being written to (since these writes are not being done by the emulated CPU, the CPU does not set the dirty bit on these writes as it does on all other writes).
After implementing this optimization, you should only do as many page reads and writes to the swap file as necessary to execute the program, and as dictated by the page replacement algorithm.
Note that parts 3 and 4 do not depend on each other. You can implement part 3 before part 4, and vice versa.
Testing: Use the same tests as with the previous parts. With this optimization, you should notice that the number of writes to the swap file (pageouts) decreases (sometimes significantly). In particular, you should notice a substantial difference in the number of pageouts between swap4 and swap5 since swap5 modifies the data in its memory.
4. (7%) In part 2, when handling a page fault we recommended using a simple locking strategy that acquires and holds a lock for the duration of your page fault handler. While simpler to implement, this strategy limits performance: when one process is handling a page fault — which may take milliseconds to complete — no other process can use the virtual memory subsystem (create new processes, handle their own page faults, etc.). In this part, you will optimize page replacement by allowing multiple processes to use the virtual memory subsystem in a more fine-grained manner. Note that this optimization is only useful once you have paging support for multiple processes working.
There are two aspects to implementing this optimization. The first is that you will need to modify the locking strategy from part 2: the process must release the lock before performing an I/O operation to the COFF file or swap file, and acquire it again when the I/O operation completes. Put another way, the requirement is that while a process performs an I/O operation to COFF or swap, the process cannot hold any locks.
The second is that when your code is using a physical page for copying data with readVirtualMemory or writeVirtualMemory, or when it is performing an I/O operation to the COFF file or the swap file, it will need to "pin" the physical page while using it so that no other process can choose it for eviction. When the I/O completes, the process will unpin the page. Consider the following actions:
In this example, the page to which A is writing should be pinned in memory so that it is not chosen for page eviction. Otherwise, if process B evicted the page, then when process A was rescheduled it would write to the page B loaded. This same scenario also applies if process A were evicting a page to the swap file (page out), or reading a page in from the swap file (page in). You can use your inverted page table to keep track of which physical pages are pinned.
Finally, it is possible that a process needs a page, but not only are all pages in use (meaning an eviction must occur), but all pages are pinned (meaning an eviction must not occur now ). Handle this situation using synchronization. If process A needs to evict a page, but all pages are pinned, block A on a condition variable. When another process unpins a page, it can unblock A. In terms of prioritizing, implement this functionality at the very end.
Note that parts 3 and 4 do not depend on each other. You can implement part 4 before part 3, and vice versa.
The only system call that these programs use is exit (none of the system calls that use rVM/wVM need to work). You can also use the two programs in the test directory that just compute on data in memory: matmult (which exits with 7220) and sort (which exits with 0). If you comment out the printf in matmult.c, then these programs also only use the exit system call.
% nachos -m 64 -x swap4.coff
In contrast, when you start implementing swapping in part 2 you will want to explicitly control and reduce the number of pages (and thus, indirectly, the necessity to swap), such as:
% nachos -m 8 -x swap4.coffYou can also modify nachos.conf in the proj3 subdirectory to control the default amount of physical memory. Note that your implementation should not depend upon any particular number of physical pages, but we will always test with at least four physical pages. When testing with multiple processes, we will test with at least twice the number of physical pages as processes (e.g., eight pages with four processes).
As with the previous projects, during the project period you can also use Gradescope to run a snapshot of your code on the sample tests that we have given. Important: As with the previous projects, before the deadline you must submit your code to Gradescope at least once to initialize the grading system for your project.
As a final step, create a file named README in the proj3 directory. The README file should list the members of your group and provide a short description of what code you wrote, how well it worked, how you tested your code, and how each group member contributed to the project. The goal is to make it easier for us to understand what you did as we grade your project in case there is a problem with your code, not to burden you with a lot more work. Do not agonize over wording. It does not have to be poetic, but it should be informative.
We will use a snapshot of your Nachos implementation in your github repository as it exists at the deadline, and grade that version. (Even if you have made changes to your repo after the deadline, that's ok, we will use a snapshot of your code at the deadline.) Important: Before the deadline, you must submit your code to Gradescope at least once.
If you encounter problems with your account (command not found, disk quota exceeded, class file has wrong version, etc.), see these troubleshooting tips.
You can discuss concepts with students in other groups, but do not cheat when implementing your project. Cheating includes copying code from someone else's implementation, copying code from an implementation found on the Internet, or using generative AI or LLMs. See the main project page for more information.
We will manually check and also run code plagiarism tools on submissions and multiple Internet distributions.