Srping 2005

Project 2 - Paging Algorithm Performance

As we have discussed in class, the choice of a page replacement algorithm can greatly affect the performance of a computer system. In this project, you will simulate several different algorithms and test their performance on memory trace files of programs running on a Linux system.

The Simulator

Program speed matters, so I suggest C or C++, though Java is acceptable though not preferred. Interpreted languages such as Perl or Ruby are right out.

Running the program

<yournetid.c> <number of frames> <algorithm to use> [verbose]

where:

number of frames is the number of physical frames of RAM available to the process. In general, this number will be less than 20 for this simulation.

algorithm to use is one of the following (see below for more information about which to implement):

• FIFO: First In, First Out
• GC: Global Clock
• LFU: Least Frequently Used
• LRU: Least Recently Used
• MFU: Most Frequently Used
• OPT: Belady's Optimal Algorithm
• RAND: Random

Your simulator should read input lines from standard input of the form:

0x40000c35 W
0x40000c36 W
0x40011ac7 R
0x40011aca R
0x40000c44 W

where the first hex value is the address being accessed, and the second value indicates a read or write at that memory address. We are using standard input because the trace files are very large when uncompressed. We won't uncompress them. Instead, we will use gzcat to spew the uncompressed trace file, and pipe the output into our simulations. For example, a run might look like:

gzcat gpp.gz | clay 10 opt

Algorithms to Implement

At least two of these three:

• FIFO: First In, First Out
• GC: Global Clock
• LRU: Least Recently Used
• OPT: Belady's Optimal Algorithm

and 3 minus however many of the above you implemented of the following:

• LFU: Least Frequently Used
• MFU: Most Frequently Used
• RAND: Random

Output

Number of memory accesses:
Number of disk reads:
Number of disk writes:

Additionally, if the verbose flag is set, it should output a message every time a page is replaced. This message should indicate the hex address of the page being replaced, the page replacing it, and whether the replaced page is overwritten or written to disk first. For example:

Page 60970 overwritten by 60929
or
Page 60970 swapped, replaced by 60929

Trace Files

These traces files were gathered on a Linux system using pin. They have been reduced in terms of the number of references, however, because full traces are prohibitively large. They are listed below in order of number of memory accesses.

• g++ compilation of an 071 final project, ~320K references: gpp.gz
• A portion of an emacs run, ~2M references: emacs.sm.gz
• A few seconds of the top utility running, ~5M references: top.gz
• A run of the 071 infamous starfish solution, ~7M references: stars.gz
• A longer part of an emacs run, ~10M references: emacs.gz
• Latex run of a single page letter of recommendation, ~31M references: latex.gz

Instead of having to download everything to your own directory (though you can if you want) you can probably reach each of these files on daruma using the path: ~clay/public_html/classes/spring2005/os/

The need for speed

You can time your programs like this:

gzcat emacs.sm.gz | /usr/bin/time clay 10 opt

You will get additional output that looks like this:

real 5.8
user 4.3
sys 0.7

The time we are most interested in is the user time, since that is how much CPU time your program took to run on that trace. There will be a bonus for fast programs, and a deduction for really slow ones.

What to turn in:

• The code of your simulator, with a daruma command line on how to compile it included in the header comments.
• A nicely formatted (meaning printable) report that shows the results of each of your implemented algorithms on each trace file, including timing information.