Demystifying the MMU - Part II

In Part I of this article series, we saw the problems OS designers faced when they had to share the computer’s memory between multiple processes. We hinted that a separate hardware unit called the MMU was added to help OS designers solve these problems. In this article, we will look at the functionality of the the MMU and how exactly these problems were solved by the MMU. But before that lets take a quick digression into emergency numbers in telephone systems.

To help people understand the MMU, we would like to use the Emergency Number service as an analogy. All phones have a phone number associated with them. A call can be made to the phone by dialing its phone number. Let’s call these phone numbers associated with a phone as physical phone numbers. The following figure shows a bunch of phones and their associated physical phone numbers.

Apart from the regular phone numbers, there are emergency numbers like 100, 101 and 102, for Police, Fire and Ambulance respectively (this is specific to India, but we hope others can relate to it). These numbers do not correspond to a physical phone. When any of these numbers are dialed, the number is mapped to another physical phone number by the local telephone exchange, and the call is redirected to that physical phone. The exchange maintains a table that maps the emergency phone numbers to physical phone numbers. We call these emergency numbers as virtual phone numbers, since they are always converted by the local telephone exchange to a physical phone number. The virtual phone numbers are not directly associated with a particular physical phone.

The advantage of emergency numbers is that, when the user moves from one city to another, the local exchange will map the emergency numbers to local services of that city. That way the user does not have to remember / figure out the physical phone number for each local emergency service.

The CPU and memory is connected using the System Bus, as shown in the following diagram.

The MMU sits between the CPU and System Bus.

With the MMU in place, the addresses generated by the CPU are called Virtual Addresses. The MMU takes these addresses and translates them to Physical Addresses, using a mapping table. Just like the telephone exchange translates virtual phone numbers to physical phone numbers, the MMU translates virtual addresses to physical addresses.

Now that we know how the MMU functions, let’s see how the OS utilizes the MMU.

When a process P1 is started, the OS loads the corresponding code and data into available physical pages. It then creates page table entries that maps a set of virtual pages to those physical pages, as shown in the figure below. When the CPU generates virtual addresses in the range 0x0000_1000 - 0x0000_2000 it ends up accessing P1’s code and data.

When another process P2 is started, the existing page table entries are cleared. The OS loads P2’s code and data into available physical pages. It then creates page table entries that maps a set of virtual pages to those physical pages, as shown in the figure below. When the CPU generates virtual addresses in the range 0x0000_1000 - 0x0000_2000 it ends up accessing P2’s code and data.

It should be noted that the OS gives each process its own page table. When the OS switches to a process, the process' page table entries are loaded, and the corresponding mapping takes effect. The same virtual address 0x0000_1000 is mapped to different physical address depending upon which process is executing.

This is similar to moving from one city to another city and dialing the same emergency number. Even though the emergency number is the same, since the mapping has changed, the user ends up calling a different physical phone number.

It is to be noted that, it is not necessary to have mapping for every virtual page. If the CPU generates a virtual address that corresponds to a unmapped physical page, then the MMU raises a Page Fault interrupt to the CPU.

The OS handles the page fault interrupt, and will generally terminate the err-ing process. That is when the user sees the notorious "Segmentation Fault" message on the terminal.

In this section, we will look at how the issues discussed in Part I of the article are resolved.

Despite the fact that the page table is only mapping on a page-to-page basis, the no. of page table entries is quiet large. For a 4K page size, about 1048576 entries are required. Providing such memory to store the page table entries within the MMU in practice is not feasible.

So processors, provide space for a small no. of page table entries, say 512 or 1024, called the Translation Look-Aside Buffer (TLB). Actual mapping is stored in RAM, using a data structure optimized for space and lookup. When the MMU needs to do a translation, it first looks into the TLB for a mapping. If the mapping is not found the required entry needs to be fetched from the data structure in memory into the TLB, and the translation is re-tried.

In summary, the entire page table is not stored within the MMU. Rather a cache called the TLB, is used to store recently accessed page table entries. And required page table entries are loaded into the TLB on demand.

Through this two part article article series, hope we have acheived the following:

Please feel free to share your thoughts in the comments section below.