Project 2: Virtual Memory Management
This project entails writing a simulator for experimenting with page replacement algorithms.
The project is due on Thursday, 3/12 at 9 pm .
The goals for this project are to:
You are developing a new portable computer that combines and MP3 player, cell phone, and web browser. You have been tasked with figuring out (a) how much memory the system needs, and (b) what page replacement algorithm to use, and (c) how much benefit comes from using larger pages.
To do this, you will write a paging simulator. It will take as parameters the organization of the simulated system, read in a data file specifying the memory access behavior of programs, and will simulate the paging of those programs.
As output, it will print out the number of page faults.
Using this information, you will prepare graphs showing page faults as a function of system organization, to allow the designer to figure out how to organize the system.
As input, you will receive memory traces. Support code for parsing these files is available in
Memory trace files contain a list of addresses accessed by a program. The addresses are truncated to virtual page numbers by removing the lower 12 bits, which makes the files smaller. Here is an example for PowerPoint program:
12f 77f46 12f 7ffde 12f 77f3d 12f 7ffde 12f
Thus, the page size of the trace is fixed at 4 kilobytes. As an aside, the even numbered addresses (e.g. index 0,2,4) are instruction addresses and the odd numbered addresses (e.g. at index 1,3,5) are data addresses. This accounts for the alternating low values (instructions) and high values (data).
Code for parsing this file will be provided with the functions
The memory traces are available in the
Simulating page replacement
Your simulated machine will have a fixed number of physical pages usable by the process and its page table. Hence, when the memory required by the running programs exceeds the available physical memory, you will need to store some of the memory on a disk.
You will simulate this by keeping track of which pages are in physical memory and which are on disk. For memory reference that process executes, you should check whether the virtual page it accesses is in physical memory. If so, advance to the next address. If it is not in physical memory, you must simulate a page fault, which means selecting a page to remove and assigning its page frame to the new virtual page.
You must keep track of which pages are in physical memory and which are on disk. Assume that all pages start off on disk and you are doing demand paging. Because writing pages to disk is free, you don't have to worry about whether a page is dirty or not (and in fact, the trace does not indicate whether a memory reference is a read or a write). You should report the number of page faults it experienced. In addition, when the simulation terminates, you should report the page fault rate: the number of pages faults per memory reference.
You should experiment with total physical memory sizes of 256 KB , 1024 KB , and 4096 KB.
Page replacement policies
You should simulate four different page replacement policies, specified as a command line parameter:
For the provided scheduling traces, you should try all four page replacement policies to see how each one performs. For policies that require linked lists, there is sample code under
Simulating Different Page Sizes
The device manufacturer would like to know whether to support only 4 kb pages, or whether to support either larger pages or both small and large pages. You should experiment with these page sizes:
If you finish this project early, you can earn up to 15% extra credit by trying to invent your own page replacement policy. Wikipedia lists several policies you could try.
The extra credit will be a competition: we will run your extra replacement policy on a set of programs with an medium (not small) amount of memory. The team with the best policy will get up to 15% extra credit, and other teams will receive proportionally less based on their rank.
You should write a 3-5 page (single spaced 11 point fount, double spaced should be 5-8 pages) document describing your system and explaining your results. You should select four applications from the trace files for experimenting, and present results across all four. As the machine you are helping design
For each experiment, explain the differences in performance between the different configurations.
This project will be done in groups of 3. As with the last two projects, you are free to organize the work however you liked. However, we recommend that you decide on an architecture and division of labor in advance.
In the first week of the project, you should design your simulator, figuring out what the major modules are and what they do. You should write a specification of the interface to each module. For example, you may have a page table module that keeps track of which pages are in memory, and a page replacement module that figure out which page to replace on a page fault. You need to write the interface, in terms of what functions they provide and what structures they use, to each of the interfaces so that other members of your team can program against the interface before it has been implemented.
You should think about the data structures you will need: how can you support the different page replacement algorithms and page sizes with a single set of data structures?
Simulator speed is important: if you use inefficient algorithms or data structures, it may take days for your simulations to run. For this reason, you should think about how you will efficiently maintain implement each module. Consider the complexity (linear, quadratic, exponential) of each piece of your simulation as part of the design.
You should start coding the data structures and a simple replacement policy, such as none: assume infinite memory and never replace anything.
In addition to specifying the interface, you should create a division of labor that includes (at least) these roles:
After the first week, each team will meet with an instructor to discuss their design.
In the second week, you should implement the additional page sizes and replacement polices, and then run your experiments.
The command line for your simulator should be: mem-sim kb page-size pr-policy trace-file where
The output of the simulator should be:
You should experiment with total physical memory sizes of 256 KB, 1024 KB, and 4096 KB.
You should run experiments with FIFO, 2nd-chance FIFO, LRU, and Clock page replacement algorithms.
You should run experiments with 4kb, 8kb, and 16kb pages.
What to turn in
Turn in your code to the directory ~cs537-1/handin//P2 by the specified due date for the code. Email your project writeup directly to the instructors by the due date for the writeup.