In this milestone you need to implement demand-paging of memory to a backing store. This should build on the provided frame table and the earlier milestone where you implemented a virtual memory system. The backing store for your paging system will be an NFS file called pagefile. You should implement a second-chance page-replacement algorithm.

Design issues

Most of the design in this section will come down to the appropriate choice of data structures. If you haven't already done so, you will need to work out your page table structure. You will also need to decide how to keep track of pages in your paging file. You may want to keep things simple at first by only concentrating on one process, however you should be aware that the next milestone will require you to handle multiple processes.

The ARM aarch64 virtual memory architecture does not provide a hardware-maintained reference bit. To implement second-chance page replacement you will need to simulate one in software. Judicious unmapping can be used to detect future references to maintain a reference bit.

Assessment

Demonstration

To demonstrate that your code is indeed using the paging system you should artificially reduce the number of free frames, and run a program which uses a large heap and a large stack. You may reduce the number of frames in the frame table by setting SosFrameLimit when running init-build.sh to a value other than 0ul.

For example, the following would limit the frame table to 16 frames (64k) of memory.

../init-build.sh -DSosFrameLimit=16ul

Note: Choose a large difference between RAM and the paging file size, (e.g. at least 10 times the reduced RAM) to ensure you can clearly demonstrate paging extending the available memory to run applications larger than available RAM.

You may want to write a command called thrash which writes data to a given number of pages and then reads it back (verifying that it has been read back correctly).

Show Stoppers

• Solutions that leak free space in the paging file. For example, using a bump pointer to manage allocation in the page file.

Better Solutions

• Solutions that do not increase the page table entry size when implementing demand paging.
• Avoid paging out read-only pages that are already in the page file.
• In theory, support large page files (e.g. 2-4 GB)
• Solutions that avoid keeping the entire free list of free page-file space in memory.