Comp 430 Final Project: Tracking Page Faults
Introduction
The goal of this project is to modify the Linux kernel so that it
maintains a per-process record of page faults. You should record the
list of addresses that result in page faults, and those addresses
should be made available through appropriate entries in the proc/ file
system. This information could have several uses. It could be used
for application tuning by giving insight into memory access patterns
of individual programs. It could also be useful information for
profiling or debugging the Linux memory management system itself.
For this project you may work alone or in pairs. The main challenge
in this project will not be writing the code. The challenge will be
reading the existing code, and doing the research to figure out how
the problem can be solved.
One complication you will need to deal with is the fact that there is
no upper bound on the number of page faults that a particular process
might experience. This causes two different problems. First, it
means the data structure that stores addresses must be able to grow.
Second, it turns out that smallish fixed sized files are easier to
deal with in the proc/ file system than large files. (You can find
information on the proc/ file system in
Documentation/filesystems/proc.txt and in
Chapter
4 of
Linux Device
Drivers)
With that in mind, it might make sense to start out by setting up a
system that only maintains and prints a smallish circular array of
addresses.
The project has two deadlines. For the first deadline, Wednesday of
9th week, you should submit answers to the following list of
questions. These are designed to give you a starting point in thinking
through what needs to be done.
- Where in the kernel are page faults handled?
- Where is mm_struct defined?
- Where is mm_struct initialized?
- Where should the list of addresses be stored?
- Where are the per-process entries in the proc/ file system set up?
Handing In
Your final submission should take the form of a
tarred directory as described in
HW #1 . That directory should contain the
following items:
- A patch file representing your modifications to the kernel.
I'll test your submission by applying this patch, so you should test
it before you submit it.
- A test application that generates an interesting pattern of
memory accesses. Possibilities include:
- Allocate a very large region of memory (larger than the
physical memory of the system) and write a loop that fills it entirely
with 1's. Since the kernel will be forced to swap out old frames to
make room for later ones, this should give some insight into the
mechanism used to select victim frames.
- Allocate a large region of memory and write 1's to randomly
generated locations in that memory. This violates spatial locality,
and should generate many page faults quickly.
- Write a program that involves very deep recursion. This
should generate many page faults on the stack.
- A figure illustrating the page fault pattern generated by
your test application. Keep in mind that the overall address space is
huge. You will probably need to zoom in on smallish regions in order
to see any interesting structure.
- A plain text README documenting your project. This file
should include a listing of all files you modified, along with a
description of the modifications. There should be enough information
here for someone to reproduce what you have done, and understand all
of the steps. You should include information on known bugs, as well
as anything else I need to know to evaluate your work.
Grading
| Answers to Questions (Due Date 1) |
10% |
| Documentation |
15% |
| Coding Style |
15% |
| Patch Functionality |
50% |
| Test Application and Figure |
10% |
This page is maintained by Nathan Sprague nsprague{at}kzoo{dot}edu.