Project 4: Memory Simulator

Update: Please read the FAQ for Project Four.

Project Goals

By undertaking this project, you will:
  • learn how to implement page replacement algorithms.
  • gain experience in creating and evaluating a simple simulator.
  • develop your skills in scientific writing.
  • Introduction

    In class, we have explored a variety of page replacement algorithms for managing virtual memory. The proper choice of a page replacement algorithm is actually quite a complex matter. To make the proper choice, we must know something about real applications. How do they really access memory? Do they generate many page accesses in order? Do they skip around memory randomly? To answer these questions, we must see what real applications do.

    In this project, you will evaluate how real applications respond to a variety of page replacement algorithms. Of course, modifying a real operating system to use different page replacement algorithms is quite a technical mess, so we will untake this project by simulation. You will write a program that simulates the behavior of a memory system using a variety of page replacement algorithms. We will provide memory traces from real applications so that you can evaluate your algorithm properly.

    The result of your work will be a lab report that describes your simulator and what you have learned by applying it. The report itself will be a significant fraction of your grade, so you should be sure to spend time thinking about what to measure, and what the significance of your results are.

    At the completion of this project, you will turn in both your simulator code as well as the final lab report.

    Memory Traces

    We provide with you four memory traces to use with your simulator. Each trace is a real recording of a running program, taken from the SPEC benchmarks. Real traces are enormously big: billions and billions of memory accesses. However, a relatively small trace will be more than enough to keep you busy. Each trace only consists of one million memory accesses taken from the beginning of each program.

    Here are the traces:

    Each trace is compressed with gzip, so you will have to download each trace and then uncompress it with a command like this:

        % gunzip gcc.trace.gz
    

    Each trace is a series of lines, each listing a hexadecimal memory address followed by R or W to indicate a read or a write. For example, gcc.trace trace starts like this:

        0041f7a0 R
        13f5e2c0 R
        05e78900 R
        004758a0 R
        31348900 W
    
    Note, to scan in one memory access in this format, you can use fscanf() like so:
        unsigned addr;
        char rw;
        ...
        fscanf(file,"%x %c",&addr,&rw);
    

    Simulator Requirements

    Your job is to build a simulator that reads a memory trace and simulates the action of a virtual memory system with a single level page table. Your simulator should keep track of what pages are loaded into memory. As it processes each memory event from the trace, it should check to see if the corresponding page is loaded. If not, it should choose a page to remove from memory. Of course, if the page to be replaced is dirty, it must be saved to disk. Finally, the new page is to be loaded into memory from disk, and the page table is updated. Assume that all pages and page frames are 4 KB (4096 bytes).

    Of course, this is just a simulation of the page table, so you do not actually need to read and write data from disk. Just keep track of what pages are loaded. When a simulated disk read or write must occur, simply increment a counter to keep track of disk reads and writes, respectively.

    You must implement three different page replacement algorithms. rand replaces a page chosen completely at random. lru always replaces the least-recently-used page. ws performs the pure working set algorithm described in the textbook. (The working set k parameter is given on the command line.)

    You are free to structure and write your simulator in any reasonable manner. However, we must impose some strict requirements on the interface to your simulator so that we will be able to test and grade your work in an efficient manner.

    Your simulator must be written in plain C and contained in a source file called memsim.c. The simulator should take the following arguments:

        memsim <tracefile> <nframes> <rand|lru|ws> <debug|quiet> <k>
    

    The first argument argument gives the name of the memory trace file to use. The second argument gives the number of page frames in the simulated memory. The third argument gives the page replacement algorithm to use. The fourth argument may be "debug" or "quiet". (Explained below.) The final argument should be the working set K parameter. The units of K are simply trace events. That is, if K is 5, then the working set should be computed over the last five trace events.

    If the fourth argument is "quiet", then the simulator should run silently with no output until the very end, at which point it should print out a few simple statistics like this:

    total memory frames:  12
    events in trace:      1002050
    total disk reads:     1751
    total disk writes:    932
    
    If the fourth argument is "debug", then the simulator should print out messages displaying the details of each event in the trace. You may use any format for this output, it is simply there to help you debug and test your code.

    Lab Report

    An important component of this project will be to write a lab report describing and evaluating your work. You should think of this project as if it were a lab experiment in a physics or chemistry class. Your goal is to use the scientific method to learn as much as you can about the provided memory traces. For example, how much memory does each traced program actually need? What is the working set of each program? Which page replacement algorithm works best? Does one algorithm work best in all situations? If not, what situations favor what algorithms?

    Your lab report should have the following sections:

    Introduction A section that explains the essential problem of page replacement and briefly summarizes the structure and implementation of your simulator. Do not copy and paste text from this project description. In your own words, describe the overall structure and purpose of the experiment.

    Methods - A description of the experiments that you performed in order to learn something about each memory trace. Of course, it is impossible to run your simulator with all possible inputs, so you must think carefully about what measurements you need to answer the questions above. Make sure to run your simulator with an excess of memory, a shortage of memory, and memory sizes close to what each process actually needs.

    Results - A description of the results obtained by running your experiments. Present the results using graphs that show the performance of each algorithm on each memory trace over a range of available memory. When using the working-set algorithm, you should also vary the K parameter. In the text, summarize what each graph or table shows and point out any interesting or unusual data points.

    Conclusions - Describe what you have learned from the results. What have you learned about the memory traces? What have you learned about the paging algorithms? Be sure to describe clearly how specific results above lead you to these conclusions.

    The majority of your lab report grade will be drawn from the methods, results, and conclusions. Think carefully about how to run your simulator. Do not choose random input values. Instead, explore the space of memory sizes and K parameters intelligently in order to learn as much as you can about the nature of each memory trace.

    As with any written matter, the lab report must be well structured, clearly written, and free of typos and grammatical errors. A portion of your grade will cover these matters.

    There is no length requirement for this report. Use enough space to say what needs to be said. A one page report is probably too short. A ten page report is probably too long.

    How to Turn In

    This project is due at 5pm on Tuesday, April 5. Late assignments will not be accepted!

    Your entire program should be contained in a single file memsim.c. To hand in this file, simply copy the source file memsim.c and nothing else into /afs/nd.edu/coursesp.05/cse/cse341.01/dropbox/YOURNAME/p4. We will compile and test your code on the Fitzpatrick cluster, so be sure to build and test your code on those machines.

    To hand in the lab report, deliver a printed copy to Prof. Thain's mailbox in 384 Fitzpatrick Hall before the deadline.

    The grade on this project will take into account the correct implementation of the simulator (40%), good coding style (10%), insightful methods, results and conclusions (40%), and good writing style. (10%)


    Notre Dame - CSE Dept - CSE 341