Why TLBs Matter: Unlocking Faster Memory Access in Modern CPUs

TLB (Translation Lookaside Buffer) is a high‑speed cache that stores recent virtual‑to‑physical address translations, reducing the need for expensive page‑table walks.

MMU Operation and Page Tables

The MMU translates virtual addresses to physical addresses using a hierarchical page table. Typical 64‑bit systems use a four‑level page table: PGD → PUD → PMD → PTE. A page‑table‑base register holds the address of the top‑level PGD.

The MMU walks the page table levels to locate the physical frame. This four‑step walk incurs four memory accesses and can become a performance bottleneck.

What Is the Essence of a TLB?

A TLB is essentially a cache for virtual‑to‑physical address mappings. When a virtual address is looked up, the TLB is consulted first; a hit returns the physical address immediately, while a miss triggers a full page‑table walk and the result is then cached in the TLB.

Special Characteristics of the TLB

Because the translation granularity is 4 KB, the low 12 bits of the virtual and physical addresses are identical and need not be stored. Whether an index field is required depends on the cache organization (fully‑associative vs. set‑associative). Modern CPUs often use a 48‑bit virtual address space, leaving the upper bits unused.

Alias Problem

TLB entries map a virtual address to a physical address. For a single process, one virtual address maps to one physical address, but the same physical address can be mapped by multiple virtual addresses, so the TLB does not suffer from aliasing in the same way a VIVT cache does.

Ambiguity Problem

Different processes may use the same virtual address to refer to different physical pages. If a TLB entry from process A remains after a switch to process B, B could incorrectly access A’s data, causing ambiguity. The common solution is to invalidate the entire TLB on a context switch, which hurts performance.

How to Minimize TLB Flushes

One approach 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.

Managing ASIDs

ASIDs are typically 8 or 16 bits, allowing 256 or 65 536 distinct identifiers. The kernel assigns an ASID to each new process, stores it in the task_struct, and may also keep it in unused bits of the page‑table‑base register. When ASIDs are exhausted, all TLB entries are flushed and the bitmap is cleared.

Shared Kernel Mappings

Kernel space is shared among all processes. To avoid unnecessary flushes for global mappings, the final level page table includes a non‑global (nG) bit. If the mapping is global, the TLB can be considered a hit without comparing ASIDs.

When Should the TLB Be Flushed?

When the ASID pool is exhausted and a new ASID must be allocated.

Whenever a new page‑table entry is created, the corresponding TLB entry must be invalidated to avoid stale translations.

During process context switches if the hardware does not support ASID‑aware lookups.