Hints for A3

This file is likely to be updated, so check back periodically and use your browser's refresh button.

PLEASE BE SURE TO READ ALL OF THE HINTS CAREFULLY, ESPECIALLY THE HINTS ON TESTING. IT EXPLAINS HOW WE WILL BE TESTING YOUR SUBMISSION.

Quick Topic Links

• I didn't get the A2 system calls working
• Once I implement the read-only text segment, every test program fails!
• Physical Memory Management in dumbvm
• Handling TLB Faults
• TLB shootdown
• Understanding How Physical Memory is Handled
• Testing

I didn't get the A2 system calls working. What can I do?

• Most of the testing for A3 does not use A2 system calls. The only exception is the multi-process tests described in the testing section.

Once I implement the read-only text segment, every test program fails!

• When the kernel loads a program from the ELF file, it writes data from the ELF file to the process's text and data segments. When you make the text segment read-only, this may fail.
• One way to solve this problem is to make sure the text segment is writeable until the kernel has finished loading it, and then make it read-only.
• A second way to solve this problem is to take advantage of the fact that each physical memory address (at least for the first 0.5GB of physical memory) as a corresponding kernel virtual address.

Physical Memory Management in dumbvm

• In the dumbvm system, the kernel uses a function called ram_stealmem when it needs to allocate more physical memory.
• The kernel also has a function called ram_getsize (see kern/arch/mips/vm/ram.c), which is intended to be called when you are initializing your new, improved virtual memory system. It tells you how much free physical memory there is, and you will need this information when you are initializing your structure for tracking which parts of physical memory are free.
• The idea is that ram_getsize should be called exactly one time, while you are initializing your virtual memory system. Furthermore, once ram_getsize has been called, the kernel should never again call ram_stealmem to allocate physical memory! Instead, the kernel should be calling whatever function you implement to allocate physical memory.

Handling TLB Faults

• Make sure that your TLB fault handler (vm_fault) does not do anything that might cause another TLB fault. The result will be a potentially infinite nesting of TLB faults from which your kernel will probably not recover. In particular, your TLB fault handler should avoid anything that involves touching virtual addresses in the application's part of the virtual address space, since those attempts might generate faults, depending on what's in the TLB. Functions like copyin and copyout are examples of functions that touch application virtual addresses.

TLB Shootdown

• We will only be testing A3 using single processor configurations. Therefore, there is no need for you to worry about implementing the TLB shootdown functions. TLB shootdown allows one processor to request that another processor remove entries from its TLB. Since we are not testing with multiple processors, TLB shootdown will never be required.

Understanding How Physical Memory is Handled

• Look at gettppages in kern/arch/mips/mips/dumbvm.c. Notice how getppages gets more page frames when needed. When is getppages first called and why? Think about how that will have to differ in an implementation that needs some sort of data structure (e.g., a coremap) to find free pages.
• Have a look at ram_stealmem in kern/arch/mips/vm/ram.c . Understand how it works and what firstpaddr and lastpaddr are doing.
• Be sure you understand how the MIPS translates a kernel virtual address to a physical address and what that means as it relates to allocating free page frames.
• Think about how to mark the frames that are already occupied as used in your coremap. Note that there will be a bit of a chicken and an egg problem. In order to mark frames as used you will need to allocate a coremap data structure (using kmalloc). But kmalloc may be needed to find one or more free page frames to allocate.

Testing

NOTE: All tests will be done using only a single CPU.

• To run many of the existing test programs (from testbin and uw-testbin) you will need to increase the physical memory size of the machine. You can do this by editing root/sys161.conf. Look for a line that looks something like this:

  31      mainboard  ramsize=524288  cpus=1
  or
  31      mainboard  ramsize=524288  cpus=4
  

  In this example the machine has 524288 bytes of physical memory (128 4096-byte frames). Change 524288 to a larger number. The new number needs to be a multiple of 4096.
• We expect to be able to run most of these tests using command lines like this:

  % sys161 kernel "p uw-testbin/vm-data1;q"
  

  as we did for Assignment 2. However, the physical memory management tests are different - see below.
• basic virtual memory integrity and TLB tests
  We will run the following tests to check the integrity of address spaces, and to ensure that your kernel is properly handling faults when the TLB is full. In each case, we'll use a memory size of 2MB (or possibly more).

  uw-testbin/vm-data1

  uw-testbin/vm-data3

• read-only memory tests
  To test protection of read-only memory, we will run the following tests, using the default physical memory size (512 KB).

  uw-testbin/romemwrite

  tests writing to the code

  uw-testbin/vm-crash2

  tests writing to read-only data

• physical memory management tests
  To test physical memory management, we will run several user programs in sequence, without shutting down and restarting the kernel in between each program. If we do this with a pre-A3 kernel it will eventually run out of memory and fail. However, as long as each individual program fits in memory, an A3 kernel should be able to run programs sequentially forever, without crashing, since the kernel can reclaim and re-use physical memory each time a process exits.

  For example, we can run the sort program three times in sequence like this:

  sys161 kernel "p testbin/sort;p testbin/sort;p testbin/sort;q"
  

  For each of the programs, we will run it enough times (sequentially) so that physical memory will be exhausted if the kernel is not reclaiming and re-using physical memory properly when processes exit.

  We'll use a physical memory size of 2MB or possibly more for these tests.

  These are the programs that we will use in these "sequential run" tests:

  testbin/sort

  Sorts an array of numbers. The total size of this program's virtual address space is about 1.2MB.

  testbin/matmult

  matrix multiplication. The total size of this program's virtual address space is about 1.5MB.

  uw-testbin/vm-data1

  simple read/write test. The total size of this program's virtual address space is about 0.5MB.

• multi-process tests
  These tests will be similar to the physical memory management tests, i.e., we will run multiple tests in sequence without shutting the kernel down in between. However, unlike the tests above, these tests make use of fork and execv. These are the only A3 tests that require system calls from A2, and they will be worth only ten percent of the marks for A3. Therefore, it is a good idea to make sure that all of the other tests pass before trying these. You can get almost all of the marks for A3 without passing these tests:

  We'll use a physical memory size of 512 KB   620 KB or possibly more for these tests.

  uw-testbin/widefork

  uw-testbin/hogparty