View source for Memory Management Unit (MMU)

{{#set: Priority=3 | Summary=A Memory Management Unit is the hardware which
facilitates memory management, alleviating software of the (enormous)
cost of checking every load or store for validity in software.}}<!--
-->{{Path|Memory|9}}<!--
-->{{#invoke:Dependencies|add|Memory Mapping,4|Virtual Memory,4|Memory Protection,4|Context,3}}

<blockquote>
It would be a good strategy to be familiar at the simplified principles of [[Memory_Mapping|memory mapping]] and [[Memory_Protection|memory protection]] before getting too deeply into this article, as the MMU is where they meet.
</blockquote>

<blockquote>
Caveat: different MMUs will be implemented in ways which differ in detail.  This page is intended to illustrate the general principles in <em>a</em> particular way.
</blockquote>

== MMU Definition ==
A [https://en.wikipedia.org/wiki/Memory_management_unit Memory Management Unit] (MMU) is the hardware system which performs both virtual memory mapping and checks the current [[Processor_Privilege|privilege]] to keep user processes separated from the operating system — and each other.  In addition it helps to prevent [[caching]] of ‘volatile’ memory regions (such as areas containing [[Peripheral devices|I/O peripherals]].

==== MMU inputs ====

*a <strong>virtual</strong> memory address
*an operation: read/write, maybe a transfer size
*the processor’s privilege information

==== MMU outputs ====

*a <strong>physical</strong> memory address
*cachability (etc.) information

or

*a rejection ([[Memory_Fault|memory fault]]) indicating:
**no physical memory (currently) mapped to the requested page
**illegal operation (e.g. writing to a ‘read only’ area)
**privilege violation (e.g. user tries to get at O.S. space)

== Example ==
A typical MMU in a [[Virtual_Memory|virtual memory]] system will use a [[Memory_Pages|paging system]].  The <strong>page tables</strong> specify the translation from the virtual to the physical page addresses; only one <em>set</em> of page tables will be present at any time (<span style="color:green">green</span>, in the figure below) although other pages may still be present until the physical memory is ‘overflowing’, after which they may need to be “[[Paging|paged out]]”.

[[Image:page_mapping.png|link=|alt=Page Mapping]]

All the current process’ pages must be in the page tables but they <em>need</em> not all be physically present: they may have been ‘backed off’ onto disk.  In this case the MMU notes the fact and the O.S. will have to fetch them <em>on demand</em>.

As was observed in the [[Memory_Mapping|memory mapping]] article, the page table entries have some ‘spare’ space.  Part of this
indicates things like “this page is writeable” and the MMU checks each access request against this.  Only if there is a valid
mapping and the operation is legitimate will the MMU let the processor continue, otherwise it will indicate a [[Memory_Fault|memory fault]].

== Architecture ==
The figure below shows a typical MMU ‘in situ’ This translates virtual to physical addresses, <em>usually</em> fairly quickly
using a look-up (TLB).  This also returns some extra information – copied from the page tables – such as [[Memory_Protection|access permissions]].  If the virtual address is found in the (virtually addressed) level 1 cache then the address translation is discarded as it is not needed; the permission check is still performed though because (for example) the particular access could be a user application hitting some cached operating system (privileged) data.

[[Image:MMU.png|link=|alt=MMU]]

The look-up takes some time, so it is usually done in parallel (“lookaside”) with the first level cache, which is why the
level 1 cache is keyed with virtual addresses – something which is of importance during [[Context_Switching|context switching]].

== Example page table structure ==
The figure below shows a simple page table for a 32-bit machine using 4 KiB pages (2<sup>12</sup> bytes), leaving 20 bits to select the page (2<sup>20</sup> = 1048576 pages).

[[Image:page_table_example.png|link=|alt=Example page table structure]]

== Implementation ==
Because page tables are quite large – and there must be a set for each process – they, themselves need to be stored in memory.  This means that they are accessible for the O.S. software to maintain them – they must be in O.S. space for security, of course – but makes the memory access process very slow (and energy inefficient, too) because (in principle) there is one (or more) O.S. look-ups <em>before</em> every user data transfer takes place. <span style="color:red"><em>If this really had to happen the computer would be horrendously inefficient!</em></span>

[[Image:page_table_operation.png|link=|alt=Page table operation]]

In the ‘definition’, above, the MMU function was defined as a ‘black box’; a common set of page translations can be
[[Caching|cached]] locally to avoid the extra accesses, most of the time.  This is the function of the [[Translation Look-aside Buffer (TLB)|TLB]].

In practice the TLB will satisfy most memory requests without needing to check the ‘official’ page tables.  Occasionally, the
TLB misses: this then causes the MMU to stall the processor whilst it looks up the reference and (usually) updates the TLB contents.  This process is known as “[https://www.youtube.com/watch?v=mBOdZ6nhDJg table walking]”; it is usually a hardware job so you don’t have to worry about the details in this course unit.
----
{{BookChapter|9.1.3|353-355}}
{{PageGraph}}
{{Category|Virtual Memory}}
{{Category|Memory}}