CPU TLBs Explained: Address Translation, Page Walks, and TLB Misses

Modern operating systems normally let software work with virtual addresses instead of exposing the machine’s physical memory layout directly. The memory-management unit translates those virtual addresses to physical addresses according to page tables maintained by privileged software. Doing a full page-table lookup for every instruction fetch, load, and store would make translation unnecessarily expensive, so processors cache recently used translations in translation lookaside buffers, or TLBs.

This makes a TLB fundamentally different from an ordinary CPU data cache. An L1, L2, or L3 data cache keeps copies of memory contents close to the cores. A TLB keeps mapping information needed to locate and protect those contents. A memory access can therefore have a TLB hit and still miss in the data cache, or require fresh address translation before the cache hierarchy can complete the access.

A TLB entry associates a virtual page with the information required to translate accesses for that mapping. Intel describes the TLB as hardware that caches resolved linear-to-physical translations so subsequent accesses within the same page can avoid another page-table walk. AMD documentation likewise describes a TLB as a cache of translation-table entries used by the MMU.

The exact structures are microarchitecture-specific. A processor may have separate instruction and data TLBs, additional shared or second-level translation structures, support for multiple page sizes, and identifiers that help distinguish address spaces. Their entry counts, associativity, replacement behavior, and hit latency should not be assumed from another CPU generation.

A TLB miss simply means the needed translation was not found in the relevant translation cache. The mapping can still be perfectly valid in the page tables. Intel documents that after a translation is absent from the TLB, the processor can perform a table walk through the hierarchical paging structures to obtain the mapping.

A page fault is a different outcome. If translation cannot complete under the architecture’s paging and permission rules, the processor can report a fault for software to handle. Conflating every TLB miss with a page fault greatly exaggerates what a routine translation-cache miss means: many misses are satisfied by page-table walking without requiring the application to be terminated or the requested data to come from a page file.

Page tables are hierarchical data structures in memory. When a cached translation is unavailable, page-walk hardware may need to consult multiple paging-structure entries before it can resolve the final physical page. The cost is therefore not a universal fixed number: it depends on the architecture, page-table depth, page size, implementation, and where the required paging information is found in the memory hierarchy.

Intel performance documentation exposes events for TLB misses and page-walk duration precisely because translation behavior can become measurable in memory-intensive code. That does not mean every TLB miss stalls for a full trip to DRAM. Paging-structure data can itself benefit from caching and modern processors contain implementation-specific machinery intended to reduce translation overhead.

Each cached translation covers a page-sized region. With the same number of usable translation entries, a larger page can therefore describe a larger span of virtual memory. Linux documentation calls TLB capacity a scarce resource and notes that huge pages can reduce TLB pressure and page-table overhead for suitable workloads.

That does not make huge pages a universal performance switch. Linux also documents trade-offs including wasted memory and allocation challenges, and the available page sizes and implementation details vary by architecture. Larger mappings are most relevant when translation reach is genuinely limiting a workload; they should not be presented as a blanket gaming or desktop optimization.

The general idea of caching translations is architectural, but the hierarchy around it is not identical across processors. Some CPUs expose or document first-level instruction and data TLB behavior plus a larger second-level translation cache; other designs use different arrangements. AMD’s current MicroBlaze documentation, for example, describes separate instruction and data shadow TLBs backed by a unified TLB, while other AMD and Intel cores have their own designs.

For performance analysis, use documentation and counters for the exact processor rather than carrying entry counts or miss penalties from a different architecture. The useful general distinction is simply that an early translation-cache miss may still be satisfied by another translation structure before a full page-table walk is required.

Code that repeatedly touches a compact set of pages can reuse cached translations effectively. Workloads that access a much larger or less-local set of pages can put more pressure on finite TLB resources, increasing the chance that translations must be recovered from another TLB level or through page-table walking. This is one reason memory-access locality can matter beyond ordinary cache locality.

When profiling a real application, distinguish data-cache misses, TLB misses, page walks, and operating-system page faults instead of treating them as one “memory latency” event. Hardware performance counters and OS tooling can help identify which layer is actually responsible, but the relevant counter names and interpretation are processor-specific. Optimize the measured bottleneck rather than assuming that changing page size or memory settings will help every workload.