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.
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.
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
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
), where the first address should be
, and the second should be
. 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,
. This output-part1test
file should have a similar format to the
file, as above (i.e., each physical
address should use 8 bytes (as an unsigned long value) in the
). 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
) 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
utility to compute their corresponding checksum,
and you only need to write these checksums into the
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
, 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
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:
- First, you should update the old page table entry
such that you do not have two virtual pages pointing to the same physical
- 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
, 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
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>
| ||PageSize||size of each physical frame and virtual page (in bytes)|
| ||SizeOfVirtualMemory||size of virtual memory (in bytes)|
| ||SizeOfPhysicalMemory||size of physical memory (in bytes)|
| ||SequenceFile||name 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.
Please include your status.txt
file, as well as the source
includes all source files, as well as a Makefile.
source directory: mandatory
This directory should include all of your source code (*.c
, etc.) as well as a Makefile.
Without source code, you can earn only 50% of the total points, at most.
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.