This project may be completed in either pairs or singletons. Submit your project to only one dropbox, and clearly indicate in your lab report the members of your group. Both members of the group will receive the same grade.
Once your system is working correctly, you will evaluate the performance of several page replacement algorithms on a selection of simple programs across a range of memory sizes. You will write a short lab report that explains the experiments, describes your results, and draws conclusions about the behavior of each algorithm.
% ./virtmem 100 10 rand sort page fault on page #0The program exits because the page fault handler isn't written yet. That is your job!
Try this as a getting started exercise. If you run the program with an equal number of pages and frames, then we don't actually need a disk. Instead, you can simply make page N map directly to frame N, and do nothing else. So, modify the page fault handler to do exactly that:
page_table_set_entry(pt,page,page,PROT_READ|PROT_WRITE);With that page fault handler, all of the example programs will run, cause a number of page faults, but then run to completion. Congratulations, you have written your first fault handler. Of course, when there are fewer frames than pages, then this simple scheme will not do. Instead, we must keep recently used pages in the physical memory, other pages on disk, and update the page table appropriately as they move back and forth.
|Let's work through an example, starting with the figure at the right. Suppose that we begin with nothing in physical memory. If the application begins by trying to read page 2, this will result in a page fault. The page fault handler choose a free frame, say frame 3. It then adjusts the page table to map page 2 to frame 3, with read permissions. Then, it loads page 2 from disk into page 3. When the page fault handler completes, the read operation is re-attempted, and succeeds.|
|The application continues to run, reading various pages. Suppose that it reads pages 3, 5, 6, and 7, each of which result in a page fault, and must be loaded into memory as before. Now physical memory is fully in use.|
|Now suppose that the application attempts to write to page 5. Because this page only has the R bit set, a page fault will result. The page fault handler looks at the current page bits, and upon seeing that it already has the PROT_READ bit set, adds the PROT_WRITE bit. The page fault handler returns, and the application can continue. Page 5, frame 1 is modified.|
|Now suppose that the application reads page 1. Page 1 is not currently paged into physical memory. The page fault handler must decide which frame to remove. Suppose that it picks page 5, frame 0 at random. Because page 5 has the PROT_WRITE bit set, we know that it is dirty. So, the page fault handler writes page 5 back to the disk, and reads page 1 in its place. Two entries in the page table are updated to reflect the new situation.|
./virtmem npages nframes rand|fifo|custom scan|sort|focusnpages is the number of pages and nframes is the number of frames to create in the system. The third argument is the page replacement algorithm. You must implement rand (random replacement), fifo (first-in-first-out), and custom, an algorithm of your own invention. The final argument specifies which built-in program to run: scan, sort, or focus. Each accesses memory using a slightly different pattern.
You may only modify the file main.c. Your job is to implement three page replacement algorithms. rand and fifo should be implemented as discussed in class. You should invent a third algorithm, custom that does a better job than rand or fifo. (Better means results in fewer disk reads and writes.) I strongly encourage you to choose something simple.
A complete and correct program will run each of the sample programs to completion with only the following output:
You will also turn in a lab report that has the following elements:
/afs/nd.edu/coursesp.09/cse/cse30341.01/dropbox/YOURNAME/project5This assignment is due at 5PM on Wednesday, April 8th. Late assignments will not be accepted. Your program will be compiled and graded on the Linux machines in the Fitzpatrick computer lab. Therefore, you should do your development work either sitting in that lab, or using ssh to connect to the machines remotely. The TAs will hold office hours in the lab, and will be happy to help you with those machines.
If you insist on doing the homework on your personal computer or laptop, then you are on your own. Please do not ask the TAs to fiddle around with your personal computers. Leave extra time to ensure that your program works correctly when transferred to the Fitzpatrick machines.