Computer Sciences Department
CS 537
Spring 2000
A. Arpaci-Dusseau
Quiz #8 Solutions: Wednesday, April 12

Name: Student ID #:

Memory Management and Virtual Memory

Problem 1: Page Sizes (20 points)

What is the primary performance benefit of larger pages? (Assume that the size of an address space and the amount of memory remains the same.)

With larger pages, a greater fraction of the address space can be reached from the Translation Lookaside Buffer (TLB). For example, with 4KB pages and 64 TLB entries, 256KB of the address space can be accessed without having to walk the page tables (after the first access to each page); with 8KB pages and the same number of entries, 512KB can be accessed.

This is the primary reason why modern architectures are supporting larger pages (or multiple pages sizes).

Problem 2: Dirty Bit (30 points)

In some memory systems, each page has a dirty bit associated with it.

a) When is the dirty bit set on a page (i.e., when is the page considered dirty)?

When the page is first written; i.e., when the copy in memory does not match the version on disk.

b) When is the dirty bit cleared on a page (i.e., when is the page considered clean)?

When the dirty page is written out again to disk (e.g., after it has been replaced by another page.)

c) Why is it useful to know that a page is dirty?

It is cheaper to pick a clean page for replacement than a dirty page: the clean page can be simply discarded when it is replaced, whereas the dirty page must be written back to disk. Therefore, the page replacement policy will prefer to replace a clean pages over a dirty page.

Problem 3: Emulating a Dirty Bit (50 points)

In some systems, there is hardware support for setting and clearing dirty bits. However, in other systems, there is not; in this case, software (i.e., the Operating System) can emulate the role of hardware. In this question, you are to describe the steps involved in emulating dirty bits in software.

To make your answer clear, specify any changes in how the page tables are used and any new data structures that you need. Explain what happens on a read and write to a given page; if some read or write operations act differently than others, explain each case. Make sure in your explanation that you show when the emulated dirty bit gets set and cleared.

You should assume that hardware understands the format of the page tables and performs the page translations. You should make any reasonable assumptions about the format of an address and the page tables that you find useful. Finally, make sure that your emulation performs efficiently.

The key to answering this question is to specify how the dirty page gets set without hardware support on a write operation. Remember that the operating system doesn't see every write that occurs: a write to memory corresponds simply to a STORE assembly instruction, not a system call. It is the hardware that takes care of the STORE and the necessary address translation. The only time the OS will see a memory write is when the address translation in the page tables fails, causing a trap to the OS.

Therefore, we need to set the page tables such that a memory write fails in its address translation. We assume that each page table entry has a read and a write permission bit. To ensure that memory writes fail, we set the write permission of every page in the page tables to 0 and introduce a new data structure. This new data structure tracks the real write permission for this page.

When the user application issues a read, it will proceed normally; the hardware will translate the logical page number to a physical page number through the page tables (or TLB) without incident.

When the user application issues its first write to a page, the hardware will see that the user does not have write permission to this page, so it will trap to the OS. The OS can then run whatever code it wants to. In this code, it will check the real write permission for this page in its new data structure; if the page does have write permission, the OS will set the emulated dirty bit for this page to 1 and change the write bit in the page tables to 1 as well.

On subsequent writes to this page, the hardware will no longer fault and will handle the page translation without incident. We don't need to catch subsequent writes, because we have already set the dirty bit, and the page can't get any dirtier than it already is...