Lab5 Virtual Memory

Lab5 Virtual Memory (Due date : March 26, 2004)

Objective : You will study how Linux implements virtual memory. A general architecture-independent memory model is the basis of all Linux virtual memory implementations, though any specific implementation depends on the particular hardware platform. In this project, you need to study the source code so that you can instrument the virtual memory code to detect the rate at which the system is incurring page faults.

Background : "A page fault exception is raised when the addressed page is not present in memory, the corresponding page table entry is null or a violation of the paging protection mechanism has occurred." [ULK]. Linux handles a page fault exception with the page fault handler "do_page_fault()". This handler can be found in "arch/i386/mm/fault.c". You may also need to read related contents of Chapter 4 in LKP
"The next most important piece of the port is the virtual memory emulation. An important job of the kernel is to maintain a separate memory context for each process, making it impossible for one process to access memory belonging to another. Native kernels accomplish this by allocating physical pages and doing hardware magic to map them into the appropriate location in a process virtual memory. UML emulates this first by creating a file that is the same size as the physical memory that UML has been told it has, and then by mapping this file as a whole into an area of its virtual memory that will be treated as its "physical" memory. When a process needs memory to be allocated, pages will be allocated from this area and the corresponding pages in the file will be mmapped() into the process virtual memory.

UML must also emulate hardware faults and device interrupts. The most important fault that needs to be emulated is a page fault, which happens whenever a process does an invalid memory access. In UML this generates a SIGSEGV; the handler does the necessary checking to see if the access is valid and a new page needs to be mapped into the process (if it's invalid, the process is sent the SIGSEGV). Device interrupts are generally emulated with SIGIO on the file descriptor used to communicate with the virtual device. The timer is implemented by requesting a SIGVTALRM timer from the host kernel.
SIGSEGV, SIGIO, and SIGVTALRM are the equivalent of hardware traps. Just as processes on a physical Linux machine aren't affected by hardware traps unless the kernel converts them into Linux signals, these signals don't affect any UML processes unless the UML kernel converts them into Linux signals. UML installs its own handlers for these signals, which run in UML kernel mode." ... Jeff Dike

You may also need to read some other materials: Understanding the Linux memory management

Problem Statement

Instrument the virtual memory manager
Instrument the memory manager software so that you can determine the rate at which any particular process, or the whole system, is incurring page faults. You need to define a new page fault system call that can serve the following purposed.
- Initialize your page fault frequency parameters, For example, you should specify the size of the window (e.g., time interval for observation) on the reference stream that you will consider in computing the average of page faults.
- Report the current page fault frequency in such a way that one could write a user program to use this data to create a performance meter.
Reporting the performance
Write a program that periodically calls your page fault system call to determine the current rate. Then plot the page fault frequency rate versus time. Finally, read about the vmstat command to get ideas about how to design your reporting program.

Attacking the Problem :

study source codes such as "fault.c", etc.
make the relative variables global;
do not do the floating point calculation inside kernel.

Submitting Your Assignment :
Please submit the following items to lab5 dir on elgate:

all source codes/files that you have added/modified including all related test programs and the graphs showing your test results for different parameters (e.g., different processes, different window sizes);
a README that contains the follows :
- Design, such as : How to set the window size, where do you put the instrumentation code and why, how do you design the system call, result analysis, etc..
- How to run your test program.
- Suggestions/lessons.
- List of all your files you submitted.
(New) Compiled kernel image with the new changes.

Note:

please make necessary comments on your code and especially, using some special symbols (e.g.HLK) to mark the place wherever your code begins and write the symbol in your README file. (10%)
(New) please make your figures output as .ps or .pdf files.