Project 5: The Paginator: The Virtual Page Turner
The Paginator
| Assignment Day | April 12, 2018 (Thursday night) |
| Due Date | Before Class: [Demo in Class Required] See Schedule page for date. |
Name the directory you submit P5 and submit code to csx730.
(still doing editing to clarify or formatting the text)
Overview
In this project, you will implement a virtual memory simulator in order to understand the behavior of a page table and the page replacement algorithms. Virtual memory allows the execution of processes that are not completely in memory. This is achieved by page table and page replacement techniques. A page table stores the mapping between virtual addresses and physical addresses. A page fault mechanism by which the memory management unit (MMU) can ask the operating system (OS) to bring in a page from the disk. The system we are simulating is 16-bit machine (8 bits for index and 8 bits for offset).
Part 1: Page Table
The page table structure that you will simulate is a linear page table.
Each page table entry should contain:
(1) a valid bit,
(2)
a physical page number, and
(3) ad dirty bit (denotes whether you modified the page or not)
The size of main memory (physical memory) and the size of virtual memory are configurable in
“vm.h” (#define MAX_FRAME, #define MAX_PAGE).
The machine you are simulating need to supports up to 256 pages.
Initially, physical memory is empty and a free-frame list contains every physical page. Your page allocation policy should simply hand out the physical pages in order of increasing page number, until the free-frame list is empty. From that point on, all physical pages will be obtained by page replacements algorithm. In our simulation, pages will never be added back to the free-frame list (processes never terminate).
We do not model the actual placement of virtual pages on the disk. Instead, we simply keep track of the number of disk read and write operations that are needed to handle the page faults.
- Data structure for the page table entry and statistics (hit and miss count) are defined in pagetable.h
- You will need to implement “pagefault_handler()” functions in pagetable.c file
- You will need to print out the result (pid, type(r or w), page hit, virtual addr, physical addr) for each request. Use print_result(..) function.
- You will need to update the stats. It is defined in “pageTable.stats”.
- You will need to call “disk_read()” to read a page from the disk into the main memory, and “disk_write()” to write out a dirty page to the disk.
- If the physical memory is full, you will need to call “page_replacement()” to find a victim page.
Part 2: Page Replacement
The current simulator only supports random page replacement algorithm that randomly choose a victim page.
In this part, you will implement four page replacement algorithms: First-in-first-out (FIFO), Least-recently-used (LRU) and Second-chance (Clock) algorithms.
Random is implemented already.
- LRU, Clock and FIFO functions are declared in “replacement.c”. You will need to fill out the body of each function.
- The simulator requires a command-line argument to specify a replacement policy to use.
- ./vm 0 : random (already implemented)
- ./vm 1 : FIFO
- ./vm 2 : LRU
- ./vm 3 : Clock Algorithm
Part 3: Translation Look-aside Buffer (TLB)
* (edited - title)
Page table (part 1) is located in the main memory. If we want to access location i, we must first index into the page table and it requires a memory access. It provides us with the frame number, which is combined with the page offset to produce the actual address. We can then access the desired place in memory. With this scheme, two memory accesses are needed to access a byte (one for the page-table entry, one for the byte). Thus, memory access is slowed by a factor of 2. To address this problem, we use translation look-aside buffer (TLB). It is associative, high-speed memory. Each entry in the TLB consists of two parts: a key (or tag) and a value. When the associative memory is presented with an item, the item is compared with all keys simultaneously. If the item is found, the corresponding value field is returned. The search is fast; a TLB lookup in modern hardware is part of the instruction pipeline, essentially adding no performance penalty. In this part, you will implement two-way associative TLB system. The number of TLB entry is configurable in “vm.h” (#define TLB_ENTRY).
The system supports up to 16 TLB entries and the replacement algorithm of our TLB is least-recently-used (LRU). For the simplicity, we assume that each process has its own TLB. Note that the TLB set = (PAGE_NUMBER % (#_of_TLB_ENTRY / 2)).
Input and Output:
The input format for your simulator will be in the following format:
pid R/W virtual_address
Example:
0 R 0x4a8
1 W 0x7ae
You may use a provided input generation tool “input_gen” to generate random inputs. It reads number of process, number of virtual pages, and number of physical frames from “vm.h”.
The output of your simulation should be the result of each memory request:
“[PID, R/W] TLB:hit/miss, Page:hit/miss, original_request -> physical_address”.
-
You should call “print_result” at the end of each request to print out the output.
-
At the end of a request sequence, the total number of request, the total numbers of hit and miss in pagetable and TLB, and the total numbers of disk read and write should be printed. A code for the output is already in the simulator and you will need to maintain hit, miss, disk read and disk write count.
Example of output (4 TLB entries, 8 virtual pages, 8 physical frames):
Replacement Policy: 1 - FIFO
[pid 0, W] TLB:miss, Page:miss, 0x4a8 -> 0xa8
[pid 0, W] TLB:miss, Page:miss, 0x7ae -> 0x1ae
[pid 1, W] TLB:miss, Page:miss, 0x303 -> 0x203
[pid 1, W] TLB:miss, Page:miss, 0x42e -> 0x32e
[pid 1, R] TLB:miss, Page:miss, 0x6ec -> 0x4ec
[pid 1, R] TLB:hit, Page:hit, 0x439 -> 0x339
[pid 1, W] TLB:miss, Page:miss, 0x7d0 -> 0x5d0
[pid 1, W] TLB:miss, Page:miss, 0x16 -> 0x616
[pid 0, R] TLB:hit, Page:hit, 0x742 -> 0x142
[pid 0, W] TLB:miss, Page:miss, 0x6e3 -> 0x7e3
[pid 1, W] TLB:miss, Page:miss, 0x5eb -> 0xeb
[pid 1, R] TLB:miss, Page:hit, 0x38e -> 0x28e
[pid 1, R] TLB:miss, Page:hit, 0x7bc -> 0x5bc
[pid 1, R] TLB:miss, Page:miss, 0x11e -> 0x11e
[pid 0, W] TLB:miss, Page:miss, 0x3e5 -> 0x2e5
[pid 1, W] TLB:hit, Page:hit, 0xac -> 0x6ac
[pid 1, W] TLB:miss, Page:hit, 0x52e -> 0x2e
[pid 0, W] TLB:miss, Page:miss, 0x471 -> 0x371
[pid 1, W] TLB:miss, Page:hit, 0x6a6 -> 0x4a6
[pid 1, R] TLB:hit, Page:hit, 0xd9 -> 0x6d9
=====================================
Requests: 20
Page Hits: 8 (40.00%)
Page Miss: 12 (60.00%)
TLB Hit: 4 (20.00%)
TLB Miss: 16 (80.00%)
Disk read: 12
Disk write: 4
Skeletion Provided:
P5 directory (here)
P5 zip file ( P5.zip )
Submission:
You must submit the following files (i.e., all the files necessary to
compile your project):
In addition to your pageinator you need to supply at least one input file (your_input_file.txt) and two corresponding output files (one for each algorithm). This input file is one that you have worked out by hand and have verified that you are getting the expected output (with your scheduler).
- paginator.c
- report.pdf
You need to submit all files using the submit command on nike.