Abstract
Without hardware caching, paging imposes a severe performance penalty on memory operations because translating a virtual address requires accessing physical memory multiple times to walk multi-level page tables. The Translation Lookaside Buffer (TLB) is a small, highly associative hardware cache built directly into the MMU that stores recent address translations, allowing virtual addresses to be translated to physical addresses in roughly a single CPU clock cycle.
- Category: Hardware Acceleration & Memory Caching
- Location: Built inside the Memory Management Unit (MMU) hardware.
- Performance Target: Greater than 99% hit rate in typical workloads.
Memory Translation Performance Overhead
When an application executes a memory read or write instruction, the CPU must translate the logical address before fetching data from physical RAM:
- Linear Page Tables: Requires 2 memory accesses (1 access to read the Page Table Entry, plus 1 access to read the actual data).
- -Level Hierarchical Page Tables: Requires memory accesses ( accesses to walk the page directory levels, plus 1 access for the data itself).
Because physical RAM latency is high relative to CPU clock cycles, walking a 4-level page table on every instruction fetch or variable lookup would slow program execution by .
TLB Hardware Architecture & Lookup Flow
The Translation Lookaside Buffer (TLB) exploits temporal and spatial locality—the principle that programs tend to access instructions and data within the same virtual pages repeatedly over short time windows.
TLB Hardware Characteristics
- Associativity: Implemented as a fully associative or set-associative hardware cache inside the MMU, allowing the hardware to query all cached Virtual Page Numbers (VPN) concurrently in parallel.
- Capacity: Typically holds between 64 and 2048 entries.
- Hit Latency: Extremely fast ().
Address Translation Execution Path
- Extract Virtual Page Number (VPN): The CPU isolates the VPN from the virtual address.
- Parallel TLB Query: The MMU compares the target VPN against every valid VPN entry in the TLB simultaneously.
- TLB Hit: If the mapping exists, the MMU retrieves the physical Page Frame Number (PFN) immediately, concatenates the offset, and accesses physical RAM.
- TLB Miss: If the mapping is absent, the system must walk the page table in memory, fetch the matching entry, save the PTE into the TLB, and re-execute the translation lookup.
Managing TLBs & Handling Misses
Over of address translations hit in the TLB during steady-state execution.
When a TLB miss occurs, the missing entry must be loaded from main memory using one of two architectural models:
| Handling Model | Mechanism | Advantages | Disadvantages |
|---|---|---|---|
| Hardware-Managed (x86 / ARM) | The MMU hardware walks page tables directly in RAM via the CR3 control register and updates the TLB. | Fast miss handling; no trap or context switch overhead. | Inflexible; page table structure is fixed by hardware. |
| Software-Managed (MIPS / SPARC) | The CPU raises a hardware TLB fault trap to the OS kernel. The kernel’s trap handler searches its page structures and loads the entry using dedicated instructions. | Maximum flexibility; OS can format page tables in any custom data structure. | Higher miss penalty due to trap handler state saving. |
Context Switches & Multi-Core Consistency
Because each process maintains a private address space, cached TLB mappings become invalid when switching processes.
Context Switch Strategies
- Flush Entire TLB: Invalidate all TLB entries on every context switch. Simple, but causes a wave of TLB misses when the new process starts executing.
- Address Space Identifier (ASID): Tag each TLB entry with an ASID matching the active process ID register. Mappings for multiple processes can safely coexist in the cache simultaneously without flushing.
Multi-Core TLB Shootdowns
When the OS modifies a page table entry on one CPU core (e.g., revoking permissions or unmapping memory), cached entries on other CPU cores become stale. The OS must broadcast an inter-processor interrupt (IPI) to force all cores running threads of that process to invalidate their local TLB entries—a procedure known as a TLB Shootdown.