Today : Tue, 23 Jul 19 .


CS 537 - Operating Systems - Spring 2013


HomePage Discussion Moodle Instructors Schedule Lectures Sections Readings Homeworks

Projects

edit SideBar

Project2-sp13

Page: PmWiki.Project2-sp13 - Last Modified : Wed, 06 Mar 13

Project 2: Virtual Memory

Notes

  • 3/5: updated source of page_table.c and disk.c (in zip file) for testing.
  • 3/5: The grading criteria include "user error" handling. This means the program shouldn't crash if you provide bad command line. parameters.
  • 3/4: Updated source of page_table.c (in zip file) to handle case where nframes > npages.
  • 2/28: Updated description of report to include file formats and length.
  • 2/27: Added description of 2fifo below.

You can read about second-chance fifo in the book, chapter 22 section 4. In the book it is called 'Segmented FIFO."

For second chance FIFO, partition your physical frames into two lists, ordered first-in, first-out. Each list has a fixed size. When pages are first referenced and brought in from disk, they enter the tail of the first list. When a page is added to the tail of the list, the page at the head of the list is removed (to keep it of fixed size) and moved to the tail of the second list, called the second chance list.

When a page is added to the second chance list, it should be marked invalid, which will cause a page fault if it is referenced. If a page reaches the head of the second chance list, it should be evicted. If it is referenced while on the second chance list, it should be removed from the second chance list and moved to the tail of the first list. Also, one page from the first list then moves to the tail of the second list.

Example:

  List 1: all pages are marked valid
  Tail: P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> P7 -> P8 :Head

  List 2: all pages are marked invalid
  Tail: P9 -> P10 -> P11 -> P12 :Head

After reference to page P11:

  List 1: all pages are marked valid. P11 moves to list 1
  Tail:  P11 -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> P7 :Head

  List 2: all pages are marked invalid. P8 moves to list 2
  Tail: P8 -> P9 -> P10 ->  P12 :Head

After reference to P13:

  List 1: all pages are marked valid. P13 moves to list 1
  Tail:  P13 -> P11 -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 :Head

  List 2: all pages are marked invalid. P6 moves to list 2
  Tail: P6-> P8 -> P9 -> P10  :Head

P12 gets evicted

Due Date

The project is due Thursday, March 7th at 9 pm.

Frequently Asked Questions

The goals of this project are:

  • to demonstrate mastery of virtual memory concept.
  • to learn the code mechanics of operating system fault handlers.
  • to develop skills in quantitative system evaluation.
  • to gain further experience in writing short technical reports.

This project must be completed in groups of 3. Submit your project to only one handin folder, and include a file name ''readme.txt' your report listing the group members and CS login IDs.

If you would like to form your own group, please send a single email with the members to the instructor by 2 pm on Friday, February 22nd.

Project source

A zip file is available, or you can copy the code from ~cs537-2/public/projects/p2.

Project Overview

In this project, you will build a simple but fully functional demand paged virtual memory. Although virtual memory is normally implemented in the operating system kernel, it can also be implemented at the user level. This is exactly the technique used by modern virtual machines, so you will be learning an advanced technique without having the headache of writing kernel-level code. The following figure gives an overview of the components:

We will provide you with code that implements a "virtual" page table and a "virtual" disk. The virtual page table will create a small virtual and physical memory, along with methods for updating the page table entries and protection bits. When an application uses the virtual memory, it will result in page faults that call a custom handler. Most of your job is to implement a page fault handler that will trap page faults and identify the correct course of action, which generally means updating the page table, and moving data back and forth between the disk and physical memory.

Once your system is working correctly, you will evaluate the performance of several page replacement algorithms on a selection of simple programs across a range of memory sizes. You will write a short lab report that explains the experiments, describes your results, and draws conclusions about the behavior of each algorithm.

Getting Started

Begin by downloading the source code and building it. Look through main.c and notice that the program simply creates a virtual disk and page table, and then attempts to run one of our three "programs" using the virtual memory. Because no mapping has been made between virtual and physical memory, a page fault happens immediately:

 % ./virtmem 100 10 rand sort 
page fault on page #0 

The program exits because the page fault handler isn't written yet. That is your job!

Try this as a getting started exercise. If you run the program with an equal number of pages and frames, then we don't actually need a disk. Instead, you can simply make page N map directly to frame N, and do nothing else. So, modify the page fault handler to do exactly that:

page_table_set_entry(pt,page,page,PROT_READ|PROT_WRITE);

With that page fault handler, all of the example programs will run, cause a number of page faults, but then run to completion. Congratulations, you have written your first fault handler. Of course, when there are fewer frames than pages, then this simple scheme will not do. Instead, we must keep recently used pages in the physical memory, other pages on disk, and update the page table appropriately as they move back and forth.

Example Operation

The virtual page table is very similar to what we have discussed in class, except that it does not have a reference or dirty bit for each page. The system supports a read bit (PROT_READ), a write bit (PROT_WRITE), and an execute bit (PROT_EXEC), which is enough to make it work.


Step 1
Step 2
Step 3
Step 4

Step 1. Let's work through an example, starting with the figure at the right. Suppose that we begin with nothing in physical memory. If the application begins by trying to read page 2, this will result in a page fault. The page fault handler choose a free frame, say frame 3. It then adjusts the page table to map page 2 to frame 3, with read permissions. Then, it loads page 2 from disk into page 3. When the page fault handler completes, the read operation is re-attempted, and succeeds.

Step 2: The application continues to run, reading various pages. Suppose that it reads pages 3, 5, 6, and 7, each of which result in a page fault, and must be loaded into memory as before. Now physical memory is fully in use.

Step 3. Now suppose that the application attempts to write to page 5. Because this page only has the R bit set, a page fault will result. The page fault handler looks at the current page bits, and upon seeing that it already has the PROT_READ bit set, adds the PROT_WRITE bit. The page fault handler returns, and the application can continue. Page 5, frame 1 is modified.

Step 4. Now suppose that the application reads page 1. Page 1 is not currently paged into physical memory. The page fault handler must decide which frame to remove. Suppose that it picks page 5, frame 0 at random. Because page 5 has the PROT_WRITE bit set, we know that it is dirty. So, the page fault handler writes page 5 back to the disk, and reads page 1 in its place. Two entries in the page table are updated to reflect the new situation.

Essential Requirements

Your program must be invoked as follows:

./virtmem npages nframes rand|fifo|2fifo|custom scan|sort|focus

npages is the number of pages and nframes is the number of frames to create in the system. The third argument is the page replacement algorithm. You must implement rand (random replacement), fifo (first-in-first-out), 2fifo (second-chance fifo) and custom, an algorithm of your own invention. The final argument specifies which built-in program to run: scan, sort, or focus. Each accesses memory using a slightly different pattern.

You may only modify the file main.c. Your job is to implement four page replacement algorithms. rand, fifo and 2fifo should be implemented as discussed in class. For 2fifo, you should use 25% of memory (rounded down) for the second chance list.

Your fourth algorithm targets flash drives. They have the property that if you write to the device too many times, it wears out. Thus, a paging system for flash drives should avoid writing, at the expense of a few more reads. Your task is to invent a paging mechanism with no more than 10% (on average across all three programs) more reads than second-chance fifo that reduces the number of writes as much as possible.

A complete and correct program will run each of the sample programs to completion with only the following output:

  • The single line of output from scan, sort, or focus.
  • A summary of the number of page faults, disk reads, and disk writes over the course of the program.

You may certainly add some printfs while testing and debugging your program, but the final version should not have any extraneous output. You will also turn in a lab report that has the following elements:

In your own words, briefly explain the purpose of the experiments and the experimental setup. Be sure to clearly state on which machine you ran the experiments, and exactly what your command line arguments were, so that we can reproduce your work in case of any confusion.

  • Very carefully describe the custom page replacement algorithm that you have invented. Make sure to give enough detail that someone else could reproduce your algorithm, even without your code.
  • Measure and graph the number of page faults, disk reads, and disk writes for each program and each page replacement algorithm using 100 pages and a varying number of frames between 1 and 100. Spend some time to make sure that your graphs are nicely laid out, correctly labelled, and easy to read, as discussed in class. Do not use colored backgrounds. You may connect data points with straight lines, but not with curves.
  • Explain the nature of the results. If one algorithm performs better than another under certain conditions, then point that out, explain the conditions, and explain why it performs better.

The report must be in Microsoft word .doc, docx, or Adobe .pdf format and should be between 2 and 5 pages.

Grading

Your grade on this assignment will be based on the following:

  • Correct implementation of demand paging with any arbitrary access pattern and amount of virtual and physical memory. (50%)
  • A lab report which is clearly written using correct English, contains an appropriate description of your experiments, contains correct results that are clearly presented, and draws appropriate conclusions. (30%)
  • Thorough attention to and handling of all possible error conditions, including user error. (10%)
  • Good coding style, including clear formatting, sensible variable names, and useful comments. (10%)

Turning In

Turn in all of your source code and a Makefile that builds virtmem when the user types make. Turn in a lab report named report.doc (x) or report.pdf that clearly indicates the members of your group. Please do not turn in executables or other large files. All files should be copied to your dropbox directory here: @[ ~cs537-2/handin/YOURNAME/p2 @] This assignment is due at 9PM on Thursday, March 7th. Late assignments will not be accepted. Your program will be compiled and graded on the CSL Linux machines . Therefore, you should do your development work either sitting in that lab, or using ssh to connect to the machines remotely.

If you insist on doing the homework on your personal computer or laptop, then you are on your own. This assignment is known not to work on MacOS or Windows.

Course competition

There will be a prize (similar to project 0) for the best performance of a custom replacement algorithm. Performance will be defined no more than 10% slower than 2fifo with the lowest number of writes averaged across all three programs with multiple memory sizes.

(c) Douglas Thain, 2009 Original

This page may have a more recent version on pmwiki.org: PmWiki:Project2-sp13, and a talk page: PmWiki:Project2-sp13-Talk.


Powered by PmWiki
Skin by CarlosAB

looks borrowed from http://haran.freeshell.org/oswd/sinorca
More skins here