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 .

Notes

Wednesday, 3/11

On the write-up, the assignment used to ask for average elapsed time. This is a mistake in the assignment. Rather, you should just report the number of page faults. For each experiment, you should report an average across a set of programs. You can also present individual results for these programs if you prefer. For replacement policy, for example, you can plot a bar chart showing the policy on the X axis and the average number of faults on the Y axis.
Please email your writeup to both the instructor (swift 'at' cs.wisc.edu) and the TA (aliang 'at' cs.wisc.edu).
If you are doing extra credit, please add an additional command line option "-print" which will cause your simulator to print out traces. The trace print out should have the following format:
- On a reference to a page in memory, print the virtual and physical page numbers:
vpn:pfn
- On a reference that causes a page fault, print the virtual page number referenced, the physical page, and the virtual page that is being replaced:
new-vpn:pfn:old-vpn
- If the page was empty, you can print "-1" for the old vpn.

Tuesday, 3/10

If you are implementing extra credit, use the name "extra" for the policy in the command line.

Thursday 3/6

Clarification: the memory size will be passed as a simple integer, such as 1024

Wednesday, 3/4

Added more traces for experimentation. You should evaluate at least 4 different programs for your writeup.
The specification now states the total amount of memory for testing rather than the number of physical pages. Thus, you need to divide memory by page size to get the number of pages. This ensures that when you run with bigger pages you do not also get more memory.
Updated memory size to be multiples of 16, changed specification of command line to take memory size in KB and not number of pages.

Monday 3/2

Modified 537-parse.c to stop at end of file rather than continue from beginning.

Thursday 2/26:

Group grade: at the end of this project, each person will have 40 points to allocate to their project partners (assuming 3 person groups). Your grade w ill be the points you received on the project itself plus the average number of points you were given by your partners times your percentage on the project. Thus, if you receive 80% of the project points (64/80) and average 20 points from your partners, you will get an 64+80%x20 = 80 points.
Clarified the command line parameters to specify the page size. Removed mention of flash memory.

Goals

The goals for this project are to:

Get experience with page replacement algorithms
Get experience with writing a simulation
Get experience with software engineering techniques

Project Overview

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 ~cs537-1/projects/p2 .

Memory Traces

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 open_mem_trace(), close_mem_trace(), and get_next_vpn() .

The memory traces are available in the ~cs537-1/projects/p2 and are named "programname.trace". I recommend you leave the files there rather than copying them to your directory, as they are large (5MB each).

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:

FIFO: The first page brought in is the first to be removed.
LRU: The least recently accessed page is the one to be removed
Second-change FIFO: Physical memory is partitioned so that only 75% of pages are available to a process. The remaining 25% are maintained as a second-chance queue. Page start at the end of the large queue. When a new page is brought in, the head of this queue is removed and it is added to the tail of the second queue. Access to pages in this queue cause the page to be placed back at the end of the first queue. The page at the head of the second queue is replaced.
Clock: You should maintain a clock hand that rotates around memory. Each physical page is marked "unused". Each time a page is needed, the hand advances until it finds a page marked "unused", at which time that page is chosen for eviction. If it finds a page marked "used" in this process, the page is changed to be "unused". In addition, on every memory reference, the page accessed should be marked "used".

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 ~cs537-1/projects/p2/list.h, list-sample.c

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:

4 kilobyte: this is the default
8 and 16 kilobyte: these are formed by coalescing adjacent virtual pages onto a single larger page. You can construct the virtual page number of these pages by shifting the virtual page numbers from the trace by one or two bits.

Extra Credit

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.

Write-up

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

You should explain the architecture of your simulator: what are the components, what are the interfaces between components, and why you chose this design. This is not a complete list -- you should include any policy decisions you made.
You should present three sets of experiments. For each one, you should present your results graphically (e.g., with a chart):
1. Page replacement algorithm: Pick a reasonable amount of memory and compare the performance of the page replacement algorithms in terms of total page faults experienced and the total run time of programs (i.e., the average elapsed time of all programs). If you are getting no page faults, you probably have chosen too much memory.
2. Memory size: For the best page replacement algorithm, demonstrate the difference that memory size has on page replacement. You should experiment with three memory sizes: 256, 1028, and 4096 KB.
3. Page size: For the best page replacement algorithm, choose a medium amount of memory (similar to experiment 1) and experiment with 4 kb, 8 kb, and 16 kb pages. You should report the number of page faults for each page size.
Based on these results, you should make a recommendation to the manufacturer as to (1) how much memory to put in the system, (2) what page replacement algorithm to use, and (3) what page size to use.

For each experiment, explain the differences in performance between the different configurations.

Methodology

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.

Week 1

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:

Programmer for each module: the person who writes the code.
Tester for each module: the person who writes test code for the module.
Experimenter: the person who runs the experiments for the paper

After the first week, each team will meet with an instructor to discuss their design.

Week 2

In the second week, you should implement the additional page sizes and replacement polices, and then run your experiments.

Project Specification

The command line for your simulator should be: mem-sim kb page-size pr-policy trace-file where

kb is the size of memory in kb
page-size is "4kb", "8kb" or "16kb" for the size of the page
pr-policy is one of fifo, lru, 2fifo, or clock and indicates which page replacement policy to use. extra can be used if you do the extra credit.
trace-file is the name of the memory trace file

The output of the simulator should be:

The number of pages faults it experienced.

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.

Grading Policy

50% does it work -- we will run it on traces to make sure it computes the correct runtime and number of page faults.
15% code quality -- is the code clearly written, well structured and documented, and does it handle possible errors appropriately.
15% writeup -- do you clearly explain the design of your system, clearly present your performance results, and clearly explain the differences between different algorithms, memory sizes, and quantum size.
20% group grade -- did you work well with your group?
15% extra credit