Modern processors commonly execute programs in virtual address spaces. A load or store can begin with a virtual address while the memory system ultimately needs a physical location and access permissions. Page tables hold the mapping information, but consulting their hierarchy for every memory reference would add substantial work.
A translation lookaside buffer, or TLB, keeps recently used address translations near the processor. A TLB hit supplies cached mapping information without a full page-table walk. A TLB miss triggers additional translation work even when the requested application data is already present in a CPU cache.
This makes translation caching a distinct part of memory performance.
The TLB caches page mappings rather than application data
Virtual memory normally divides address spaces into pages. A page-table entry can associate a virtual page with a physical page frame and carry attributes such as access permissions.
For a simple fixed page size, an address can be viewed as two pieces:
virtual address = virtual page number + page offsetTranslation replaces the virtual page number with information identifying the physical page frame. The offset within the page remains the offset used to select a byte inside that frame.
A TLB entry caches this mapping and related attributes. It does not cache the bytes stored at the translated address. Data and instruction caches perform that separate job.
A memory access can therefore hit in one structure and miss in another. A translation can hit in the TLB while the requested data misses in the data cache. Conversely, translation activity can miss in the TLB even when data associated with the resulting physical address remains cached.
A TLB hit avoids a page-table walk
Page tables are commonly hierarchical. The processor or operating system does not need a flat entry for every possible virtual page stored in one enormous contiguous array. Multiple levels let large unused regions consume less mapping storage.
The hierarchy has a cost: resolving an uncached translation can require reading several page-table entries. Hardware page walkers on common processor architectures perform much of this process automatically for ordinary mappings.
A TLB hit bypasses that repeated traversal. Conceptually, the fast path is:
virtual page -> TLB lookup -> physical page frameA miss takes a longer path:
virtual page -> page-table walk -> mapping -> TLB fillPage-table entries themselves can benefit from processor caches, so a TLB miss does not imply that every walk step reaches DRAM. Even so, the walk consumes cache bandwidth, lookup resources, and time that a TLB hit can avoid.
TLB reach depends on entry count and page size
A useful capacity measure is TLB reach: the amount of virtual memory that can have translations represented by a given set of TLB entries at once.
If a TLB can hold 64 translations for 4 KiB pages, its simple nominal reach is:
64 * 4 KiB = 256 KiBThis figure is not the same as CPU cache capacity. A workload can operate on data that fits comfortably in a large cache yet touch enough distinct pages to exceed a small TLB’s translation coverage.
Real processors can have separate instruction and data TLBs, multiple TLB levels, entries for several page sizes, set-associative placement, and architecture-specific sharing rules. Those details affect effective reach and conflict behavior.
The basic relation remains useful: more cached translations or larger pages can cover a larger address range before old translations need replacement.
Larger pages increase reach per entry
Suppose one TLB entry represents a 4 KiB page. The same number of entries representing 2 MiB pages covers 512 times as much virtual address space per entry.
That can reduce translation pressure for large, suitably aligned memory regions. Operating systems and applications may use larger page mappings through platform-specific mechanisms, including explicit large-page allocation or automatic promotion where supported.
Larger pages also carry tradeoffs. They require larger contiguous physical regions at the relevant granularity, can increase internal fragmentation, and can alter allocation, reclamation, copy, and migration costs. A larger mapping can also make a single translation entry cover data with different locality characteristics.
Large pages are therefore a resource and layout choice rather than a universal performance switch.
TLB misses differ from page faults
A TLB miss does not mean the requested page is absent from physical memory. It only means the needed translation was not found in the relevant translation cache.
If the page tables contain a valid mapping with suitable permissions, the processor can complete the page-table walk, populate translation state as appropriate, and continue execution.
A page fault is a different event. It occurs when address translation encounters a condition requiring operating-system handling, such as a mapping that is not currently present or an access that conflicts with page permissions. The operating system can then take action according to the mapping and fault type.
This distinction matters when interpreting performance data. Frequent TLB misses can add address-translation cost without producing a corresponding stream of major storage-backed page faults.
Permissions travel with translation state
Address translation is not merely arithmetic from one page number to another. Page-table entries also encode control information used for memory protection, subject to the architecture.
Cached translation entries can retain permission and attribute information needed for access checks. The processor must not treat stale cached permissions as permanently valid after software changes the corresponding mapping.
Operating systems therefore use architecture-defined invalidation and synchronization mechanisms when changing mappings in ways that require cached translation state to be discarded. On multiprocessor systems, invalidation can involve other cores that may hold relevant entries.
This coordination is one reason frequent mapping changes can be more expensive than editing a page-table entry in memory alone.
Process switches need translation identity management
Different processes can use the same virtual address for different physical pages. A cached translation must therefore be associated with the correct address-space context.
One approach is to invalidate relevant TLB entries when switching address spaces. Many processor architectures also provide address-space identifiers or comparable tags. Such tags let entries from multiple address spaces coexist when the hardware and operating system use them correctly.
Tagging can reduce the amount of translation state discarded during context switches. It does not make entries valid forever: mapping changes, identifier reuse, and other architectural events still require correct invalidation rules.
The practical effect is that context-switch cost depends partly on the processor’s translation design and operating-system management, not only on register save and restore work.
Access patterns can create translation pressure
Code that touches one location on each of many pages can demand many translations while moving relatively little application data. Sparse structures, large hash tables, database buffers, virtual machines, and large scientific arrays can all produce page footprints that matter independently of byte-level cache locality.
Consider a loop that reads one 8-byte value from each 4 KiB page across a large region. Each access consumes little data bandwidth at the application level, but the loop cycles through a large number of virtual pages. Translation-cache capacity can become relevant well before the total bytes read per pass appear large.
Changing data layout can sometimes pack active objects into fewer pages. Larger page mappings can increase reach where their operational costs are acceptable. Both approaches target page-level locality rather than ordinary cache-line locality.
Translation and data caching form separate constraints
CPU memory performance is shaped by several caching layers with different units and purposes. A data cache might track 64-byte lines while a TLB tracks mappings for 4 KiB or larger pages. Their capacities cannot be compared as though both store the same resource.
A workload can have strong cache-line locality but poor page locality, or the reverse. Performance counters that expose TLB events can help separate translation pressure from ordinary cache misses, although event names and precise semantics vary across processor families.
Microbenchmarks can also vary page count while holding useful bytes per page constant. Such tests need care because prefetching, page allocation, page size, cache state, processor frequency, and operating-system scheduling can affect measurements.
The structural point is clear: virtual addresses need translation state before memory references can proceed through the physical memory hierarchy. The TLB keeps recent mappings close to execution hardware, and its finite coverage creates a performance boundary separate from the capacity of caches that hold instructions and data.