What Is a TLB? Translation Lookaside Buffer Explained

A TLB, or Translation Lookaside Buffer, is a small, extremely fast cache inside a CPU that stores recently used translations from virtual memory addresses to physical memory addresses. Its job is to avoid the alternative: walking the operating system’s page tables in main memory on every single instruction that touches memory, which would be far too slow to do unconditionally.

Why translation is needed at all

Every modern operating system gives each process its own virtual address space, isolated from every other process and from physical RAM’s actual layout. This is what makes it possible for two programs to both believe they own address 0x1000 without colliding, and it’s a big part of what keeps one process from reading another’s memory. But it means every memory access a program makes has to be translated: the CPU takes the virtual address the program used and maps it to the real physical address in RAM where that data actually lives.

That mapping lives in a data structure called the page table, maintained by the operating system, one entry per page of memory (typically 4 KB on most systems). Page tables for a large process can themselves span multiple levels — a multi-level tree the CPU has to walk, following pointers from level to level, to resolve a single translation. Doing that walk from scratch on every memory access, for every instruction that reads or writes memory, would add several extra memory round-trips to almost everything a CPU does.

What the TLB caches

The TLB solves this the way caches usually solve repeated-work problems: it remembers the answer. Each TLB entry stores a virtual page number alongside the physical page number it was last resolved to, plus metadata like permission bits and which process (or address space) the entry belongs to. When the CPU needs to translate an address, it checks the TLB first. On a hit, the physical address is available in essentially one cycle — no page-table walk needed. Only on a miss does the CPU fall back to walking the page tables, and it then installs the freshly computed translation into the TLB so the next access to that page is fast.

This is architecturally similar to how L1/L2/L3 caches sit between the CPU and main memory to avoid repeated slow trips to RAM — the TLB is really a specialized cache for translations rather than for data itself, sitting directly in the path of every memory access alongside those data caches.

Why TLB misses are expensive

A TLB is small — typically tens to a few thousand entries, far smaller than a data cache — because it needs to be checked on essentially every memory operation, which means it has to be fast enough not to become the bottleneck itself. That size constraint is also its main weakness: a program that touches memory scattered across far more distinct pages than the TLB can hold will suffer a much higher miss rate, and each miss costs a multi-level page-table walk, which can be an order of magnitude slower than a hit.

This is one of the reasons memory access patterns matter for performance in ways that aren’t obvious from source code alone. A workload that iterates over data sequentially tends to reuse the same handful of pages repeatedly, keeping the TLB warm; one that jumps unpredictably across a huge address range — a poorly laid-out hash table, or a large sparse array accessed randomly — can thrash the TLB even if the equivalent data fits comfortably in a data cache. Systems sensitive to this sometimes use “huge pages” (2 MB or 1 GB pages instead of the standard 4 KB) specifically to reduce the number of distinct translations a large working set needs, letting the same TLB cover far more memory.

TLBs and virtualization

TLBs get more complicated in virtualized environments, where a guest operating system’s “physical” addresses are themselves virtual from the hypervisor’s point of view — a second layer of translation on top of the first. Modern CPUs handle this with hardware support for nested translation, but a poorly tuned virtualized workload can suffer TLB pressure from both layers at once, which is part of why virtualization-heavy cloud infrastructure and database workloads pay close attention to huge-page configuration and NUMA locality — both interact directly with how much translation overhead a workload pays.

Why this stays invisible to most developers

Almost no application code interacts with the TLB directly — it’s managed entirely by the CPU and operating system, with the OS responsible for flushing stale entries when it changes a page table (for instance, on a context switch to a different process) and the CPU responsible for the lookup and fallback walk. It matters mostly to people optimizing at the systems level: database engines managing large in-memory buffer pools, language runtimes tuning garbage collector layouts, and kernel developers deciding page sizes — anywhere a program’s memory footprint and access pattern are deliberately shaped for performance rather than left to default behavior.

The takeaway

A TLB caches virtual-to-physical address translations so the CPU doesn’t have to walk multi-level page tables on every memory access. It’s small by necessity, which makes its hit rate sensitive to how scattered a program’s memory accesses are — sequential, page-local access patterns stay fast, while access scattered across many distinct pages can force expensive misses. Most code never touches it directly, but it’s one of the quiet reasons memory layout and access patterns affect real-world performance even when an algorithm’s Big O looks identical on paper.