Unlocking the Secrets of TLB: How CPUs Speed Up Virtual‑to‑Physical Address Translation

Recently a discussion in a tech community raised questions about memory page‑fault handling, leading to an overview of MMU and TLB principles.

The TLB (Translation Lookaside Buffer) is a small, fast cache that stores recent virtual‑to‑physical address translations. When a virtual address is accessed, the CPU first checks the TLB; a hit yields the physical address immediately, while a miss triggers a multi‑level page‑table walk.

MMU Operation

In a 64‑bit system the page table is typically four levels deep (PGD, PUD, PMD, PTE). A hardware register holds the base address of the top‑level PGD. The MMU walks the hierarchy to locate the final PTE, which contains the physical frame number.

What Makes TLB Special

Because the smallest translation granularity is 4 KB, the low 12 bits of the virtual and physical addresses are identical and need not be stored in the TLB. Whether an index field is required depends on the cache organization (fully associative vs. set‑associative). An example of a four‑way set‑associative TLB is shown below.

Alias and Ambiguity Issues

Unlike a physically indexed, physically tagged (PIPT) data cache, the TLB stores virtual‑to‑physical mappings, so a single physical frame can be reachable via multiple virtual addresses in different processes. This creates potential aliasing and ambiguity when the same virtual address maps to different physical frames across processes.

Avoiding Full TLB Flushes

One solution is to tag each TLB entry with an Address Space ID (ASID), analogous to a process ID. The hardware compares both the tag and the ASID, allowing entries from different processes to coexist without flushing the entire TLB on a context switch.

Managing ASIDs

ASIDs are limited (typically 8 or 16 bits), so only 256 or 65 536 concurrent processes can have distinct IDs. The kernel allocates an ASID to each new process, stores it in the task structure, and may need to flush the TLB when the ASID pool is exhausted.

Global vs. Non‑Global Mappings

Kernel space mappings are shared by all processes (global). When a TLB entry is marked as global, the ASID comparison can be skipped, allowing a hit even after a context switch. User‑space mappings are non‑global and require ASID matching.

When to Flush the TLB

When the ASID allocator runs out of IDs, flush the entire TLB and reset the allocator.

Whenever a new page‑table entry is created, flush the corresponding virtual‑address TLB entry (or the whole TLB) because the previous mapping state is unknown.

Understanding these mechanisms helps developers and kernel engineers write more efficient memory‑management code and reduce performance penalties associated with TLB misses.