An MMU, or memory management unit, is a hardware component inside your computer’s processor that translates the memory addresses used by software into the actual physical addresses where data lives in RAM. Every time a program reads or writes data, the MMU steps in to make this translation happen, typically in a single clock cycle. It also acts as a gatekeeper, preventing one program from accessing or corrupting another program’s memory.
What the MMU Actually Does
Your computer’s processor doesn’t let programs talk directly to physical RAM. Instead, each program works with “virtual” addresses, essentially a private map of memory that the program believes is entirely its own. The MMU’s job is to convert these virtual addresses into real physical locations on the fly, millions of times per second, without slowing the processor down.
This translation system serves two purposes. First, it lets the operating system give every running program the illusion that it has a large, continuous block of memory all to itself, even though physical RAM is actually carved up and shared among dozens of programs. Second, it enforces boundaries. If a browser tab tries to read memory belonging to your password manager, the MMU blocks that access and raises an error. Without this protection, consumer devices would be, as one embedded systems overview put it, “a minefield of bugs and security exploits.”
Where It Lives in Modern Processors
Early computers used separate MMU chips that sat between the processor and memory. Starting in the late 1980s, chip designers began building the MMU directly into the processor itself. Today, every modern CPU from Intel, AMD, Apple, and Arm includes the MMU on the same silicon die as the processing cores. You can’t see it or touch it separately. It’s simply part of the processor’s internal architecture, sitting in the path between the core and the memory bus.
How Address Translation Works
The operating system divides both virtual memory and physical RAM into fixed-size blocks called pages. On virtually all modern processors, including x86-64 and ARM64 chips, the standard page size is 4 KB. For workloads that move large amounts of data, “huge pages” of 2 MB are also available.
The OS maintains a data structure called a page table that records which virtual page maps to which physical page. When your program accesses an address, the MMU consults this table to find the correct physical location. But checking the full page table in main memory every single time would be painfully slow, so the MMU uses a small, fast internal cache called the Translation Lookaside Buffer.
The Translation Lookaside Buffer
The TLB stores recent address translations so the MMU doesn’t have to look them up from scratch. When a program accesses memory, the MMU first checks the TLB. If the translation is already cached there (a “TLB hit”), the physical address is available almost instantly with no delay.
If the translation isn’t in the TLB (a “TLB miss”), the MMU performs what’s called a page table walk: it searches through the page tables stored in main memory to find the correct mapping, then loads that translation into the TLB for future use. This miss typically costs one or two extra memory access cycles. Because programs tend to access the same regions of memory repeatedly, the TLB hit rate is very high in practice, often above 99%, which keeps the translation overhead negligible for most workloads.
Memory Protection and Access Rights
Translation is only half the story. The MMU also enforces access permissions on every memory operation. Each page table entry includes permission flags that specify whether a given region of memory can be read, written to, or executed, and whether only the operating system kernel or regular programs are allowed to touch it.
This is what keeps programs isolated from each other. The operating system configures the MMU so that each program can only see its own pages. If a program tries to write to an address it doesn’t have permission for, the MMU immediately triggers an exception, halting that instruction before any damage is done. This mechanism catches common software bugs like buffer overflows and null pointer errors at the hardware level, rather than letting them silently corrupt other programs or the OS itself.
The OS can also mark pages as read-only. Shared libraries, for instance, are often loaded once into physical memory and mapped into multiple programs’ virtual address spaces as read-only. This saves RAM while preventing any single program from modifying shared code.
What Happens During a Page Fault
Sometimes the MMU encounters a virtual address that has no valid mapping at all. This triggers a special type of exception called a page fault. The processor stops executing the current instruction, saves its place, and hands control to the operating system’s page fault handler.
Page faults aren’t necessarily errors. The most common cause is that the OS moved a chunk of data out of RAM and onto disk to free up space (a process called swapping). When the program needs that data again, the page fault tells the OS to load it back into RAM, update the page table, and let the program continue as if nothing happened. The program never knows the data was temporarily elsewhere.
If, on the other hand, the program tried to access an address it was never allocated, the OS treats it as a genuine error. On Linux this shows up as a “segmentation fault,” and on Windows as an “access violation.” Either way, the OS typically terminates the offending program.
The IOMMU: Protection for Devices
A related component called the IOMMU (input/output memory management unit) does something similar for hardware peripherals like graphics cards, network adapters, and storage controllers. These devices often need to read and write system memory directly without going through the CPU, a technique called direct memory access. Without oversight, a malfunctioning or malicious device could read any part of system memory.
The IOMMU sits between these peripherals and memory, translating and restricting their memory access the same way the CPU’s MMU restricts software. Arm refers to its version as the System MMU. This is especially important for virtualization, where multiple virtual machines share the same physical hardware and each one’s devices need to be sandboxed from the others.
MMU vs. MPU
Not all processors include a full MMU. Smaller embedded processors, like those in microcontrollers running a single firmware application, often use a simpler component called a memory protection unit (MPU). An MPU can block or restrict access to specific memory regions, but it doesn’t perform address translation. There’s no virtual memory, no page tables, and no ability to give each program its own private address space. Programs work directly with physical addresses.
MPUs divide memory into a handful of configurable regions, each with its own set of read, write, and execute permissions for privileged and unprivileged code. An embedded operating system reconfigures these regions every time it switches between tasks, so each task only has access to the memory it needs. This catches bugs like illegal memory writes immediately by raising an exception, which makes tracking down faulty code much easier than debugging silent memory corruption.
The tradeoff is straightforward: an MMU provides full virtual memory and strong isolation suitable for general-purpose operating systems like Windows, Linux, and macOS. An MPU provides lighter-weight protection suitable for resource-constrained embedded systems running real-time software.