CS 3733 Operating Systems Assignment 3





Overview
This assignment is related to virtual memory management inside the operating system. Although, typically, an OS can support more than one process, you will only need to handle a single process in this assignment. You will practice the management of a page table and physical memory allocation by emulating what happens inside the OS kernel. Since we cannot operate on real hardware at the OS level, this project aims to design a simulator.

Homework will include three parts, with a combined total of 80 points.

In this assignment, we consider a tiny computing system, with 1KB physical memory, and with 12-bit virtual addresses (4096 bytes). Suppose that the size of a virtual page and physical frame is 128 bytes (i.e., with 7 address bits representing page offset). Prior to beginning your implementation, think carefully about the following questions.

You should proceed only when you fully understand the answers to these questions. Talk with your classmates, or ask for help from a TA or the instructor if you are confused.
(1) What is the number of virtual pages for each process?( Answer: 32 pages )
(2) How many physical pages (or frames) are there in total?( Answer: 8 pages )
(3) How many entries are in the page table for each process?( Answer: 32 entries )
If you can understand all of these questions, now you can proceed to design a paging system that implements a one-level page table; we only use a single level for simplicity.

Part 1: 20 points

This component will simply get you started. Assume that the page table of the process is like the following picture.

pagetable

Note that only a few entries of the process' page table are listed, as we will only use the first seven entries in Part 1.

Create a directory called assign3 for this assignment. Write a main program called assign3part1.c for this part. The program will take only one parameter, the input sequence filename, which contains a sequence of logical memory accesses. Here, each logical address is stored as 8 bytes (unsigned long). Your program should read and analyze each logical address, and translate it into the corresponding physical address based on the given page table, as shown in the above picture. Note: to simplify the work in Part 1, you can place the fixed page-to-frame mapping (as shown in the figure) into an array, before performing any address translation.

Each logical memory address is saved in a binary format. To verify that you can read the correct sequence of memory accesses, you can first print the address that you have analyzed. You can test your program with the given simple test sequence file (part1testsequence), where the first address should be 0x0000000000000044, and the second should be 0x0000000000000224. Physical addresses for these two should be 0x144 and 0x01A4.

You may also refer to the sample code to analyze the given sequence file. For each logical address in the sequence file, you will use the above given simple page table to perform the address translation, and generate a corresponding physical address. You will output the translated physical addresses into a new file, named output-part1test. This output-part1test file should have a similar format to the given part1testsequence file, as above (i.e., each physical address should use 8 bytes (as an unsigned long value) in the output file). In this assignment, we represent each logical/physical address using 64-bits (8 bytes) to enable the program to be more general.

Once you test your program with the above simple test sequence, which contains only eight memory accesses, and you are sure the program performs address translation correctly, you should use the following sequence file (part1sequence) as the input file for the logical address sequence used to generate translated physical addresses, placing them in another file called output-part1. Then, you can utilize the md5sum utility to compute their corresponding checksum, and you only need to write these checksums into the status.txt file.



Part 2: 40 points

In this part, you will be designing the page table and handling physical memory management. You will create two new source files in this part: phypages.c and pagetable.c, as well as a new main program, named assign3part2.c, plus any necessary header files. Here, phypages.c is used to manage the physical pages, while pagetable.c will manage the page table for the process.

For this part, we will also assume the same as above: the first physical frame/page is reserved for the OS, while other pages are initially free. You will use a simple physical page allocation scheme initially:
You will allocate each physical page in frame number order, starting from 1, 2, 3, .... If physical pages are available, you will always allocate from the free list at first.

Once there are no free physical frames, you will need to use one of the page replacement policies to choose a physical frame to free. We will use the LRU policy at first, which means the page that was least recently used (accessed) will be the first to be freed.

Note that once a frame is selected to be freed, you need to do two things:
  1. First, you should update the old page table entry such that you do not have two virtual pages pointing to the same physical frame.
  2. Second, you must change the page table entry of the target page to point to the frame. At the same time, you may also set up the reverse mapping on the physical frame so that we may find the page table entry when we assign this frame to other entries.
If a page was accessed recently, you should update the corresponding the placement of its physical frame so that this frame will not be evicted soon (based on the LRU policy).

The input sequence of the program is the same as that used in Part 1. Thus, you should be able to utilize the same analyzing function to obtain the corresponding virtual address, then translate it to a physical address for each memory access in the file.

In the end, you can use the same function as in Part 1 to output the translated physical address sequence into a file. For the following input sequence part2sequence, the program should generate output to a file named output-part2.

Similar to Part 1, you only need to report the md5sum checksum for the output file output-part2. In addition, your program should count the number of page faults encountered for the given logical input sequence, and this result should be reported in your status.txt file.

Part 3: 20 points

Adapting your design to generalized scenarios

For this part, we will not assume the size of a page, the size of virtual memory, or the size of physical memory. You will design a system that can adapt to any arbitrary combination of these parameters. To receive these bonus points, you should list whether you have implemented Part 3 in your status.txt file. Also, you should briefly explain how your implemented this part, in comparison to the first two parts.

You should create a new main program, named assign3part3.c, and your program should accept the following parameters:

./assign3 <BytesOfPage> <SizeOfVirtualMemory> <SizeOfPhysicalMemory> <SequenceFile>

 PageSizesize of each physical frame and virtual page (in bytes)
 SizeOfVirtualMemorysize of virtual memory (in bytes)
 SizeOfPhysicalMemorysize of physical memory (in bytes)
 SequenceFilename of the input file containing the sequence of logical addresses to translate


To test your program's Part 3 functions, you can use the parameters specified in "Part 2" as follows:
./assign3 128 4096 1024 part2sequence

Your program should generate the same output file as in Part 2.

In addition, you need to run your program with the following parameters and report the md5sum results and number of page faults for the following 2 runnings in your Report.txt:

./assign3 256 4096 1024 part2sequence

./assign3 128 4096 2048 part2sequence


In the end, give an argument why you think the implementation is correct.

Submission guideline

Please include your status.txt file, as well as the source directory that includes all source files, as well as a Makefile.

source directory: mandatory
This directory should include all of your source code (*.c, *.h, etc.) as well as a Makefile. Without source code, you can earn only 50% of the total points, at most.


status.txt: manadatory
You should include a status report in a file named status.txt. This status report should state whether you have completed Parts 1 and 2 successfully. If so, include the md5sum checksums for each of the given input sequences. For Part 2, you should also include the number of page faults for the input sequence. For Part 3, please include the required description to receive the bonus points. Please also provide a brief description of what is or is not working, as well as what progress was made on the non-working part(s).
There will be a severe penalty (50% off) if your status.txt does not align with your source code. Further, if there is no status.txt present in your submission, you will not receive any points.

Finally, please compress all files into a single zipped archive and name it as "abc123.zip". abc123 should be replaced with your abcid. prior to submission.

You will submit through the blackboard. Please including the "status.txt", and a "source" directory that includes all source code and Makefile.