A CPU executes a load from a virtual address. With a four-level page table, finding the physical frame can require reading one entry at each level before the CPU can access the requested data.

In a simplified model where every memory read takes 100 nanoseconds:

That overhead would make virtual memory painfully slow. Every instruction fetch, load, and store needs address translation, so the processor cannot afford a complete page-table walk for every access.

The solution is a small, fast hardware cache of recent translations: the translation lookaside buffer, or TLB.

The TLB caches recently used virtual-page-to-physical-frame translations and their permissions.

When the required translation is in the TLB, the processor can avoid walking the page table. Programs tend to reuse nearby addresses, so a relatively small number of cached translations can serve a large fraction of memory accesses.

A page-table entry records the mapping and permissions for one virtual page. A TLB entry caches the hardware-relevant result of that mapping.

Conceptually, a TLB entry contains:

The exact fields vary by processor. The essential mapping is:

A virtual page number plus the address-space context resolves to a physical frame number plus its permissions.

The page offset does not need to be cached. It passes unchanged from the virtual address to the physical address.

For a 4 KiB page:

The TLB caches only the top half of the translation. The offset never needs caching because it is never transformed.

The TLB does not contain the application's actual data or instructions. Those bytes are held in CPU data caches, instruction caches, or physical memory. The TLB caches only the translation needed to find and protect them.

A TLB hit occurs when the TLB contains a matching entry for the virtual page and active address-space context.

Suppose a process reads virtual address:

With 4 KiB pages:

The processor looks for a TLB entry whose key matches virtual page 0x12345 in the current address space. Assume it finds:

The MMU checks that reading is allowed and forms:

No page-table walk is needed.

Permission checking remains part of the hit path. A cached frame number does not bypass read, write, execute, or privilege restrictions because those attributes are cached alongside the translation.

The TLB lookup is performed by hardware and is designed to be extremely fast. Real processors can overlap parts of translation and cache lookup, so the steps should be understood as a logical dependency rather than a literal timing diagram for every architecture.

A TLB miss occurs when no matching cached translation is available.

The virtual page can still have a completely valid page-table entry. A TLB miss says only:

On processors with hardware-managed TLBs, the memory-management hardware walks the page table:

If the page-table walk finds a usable entry with suitable permissions, the processor can place the translation in the TLB and complete the access. The operating system is not necessarily involved.

Some processor architectures use software-managed TLB refill. On such a design, a TLB miss transfers control to a privileged handler that looks up or constructs the translation and fills the TLB. This is a different implementation choice, but it preserves the same distinction: missing from the TLB does not imply missing from the process's valid mappings.

When the TLB is full, an existing entry must be selected for replacement. Hardware handles this selection on many processors; a privileged refill handler can participate on software-managed designs. Evicting a TLB entry removes only a cached translation. It does not unmap the virtual page, free the physical frame, or remove the authoritative page-table entry.

The terms TLB miss and page fault describe different failures at different layers.

A TLB miss can end in a TLB fill:

It can also expose a condition that causes a page fault:

A page fault is a processor exception that transfers control to the operating system. A TLB miss is usually just a hardware-cache miss.

This distinction is especially important on hardware-managed designs. A program can experience many TLB misses without any page faults being reported by the operating system.

Modern processors cache both translations and contents, but in different structures.

Four combinations are possible:

The implementation details of the third case depend on cache organization, but the conceptual separation remains: translation locality and data locality are related but not identical.

A monitoring tool can therefore report low data-cache misses but significant TLB misses, or the reverse. Optimizing one does not automatically fix the other.

A simplified effective-access-time calculation shows why a high TLB hit ratio matters.

Assume:

Ignore CPU data caches and assume page-table entries must be read from memory. On a TLB hit:

On a TLB miss followed by a successful four-level walk:

Let h be the TLB hit ratio:

At a 99% hit ratio:

At a 95% hit ratio:

Reducing the hit ratio by four percentage points increases this simplified effective time from 105 ns to 121 ns.

This model is useful for arithmetic, but real timing is more complicated:

The model's central lesson remains valid: because translation is required so frequently, even a small miss rate can create substantial extra work.

Applications usually access memory with temporal locality and spatial locality.

Temporal locality means a program tends to reuse the same addresses. A loop repeatedly reading a counter or traversing a small set of objects reuses their page translations.

Spatial locality means a program tends to access nearby addresses. After one address in a 4 KiB page causes its translation to enter the TLB, other addresses in that page use the same entry.

Consider a sequential scan of one 4 KiB page:

An access pattern that touches one byte from each of thousands of pages has much weaker translation locality:

Even if few bytes are read, the pattern needs many distinct translations.

This explains why the number of bytes accessed is not the only factor in TLB behavior. The number of distinct pages touched during a short period also matters.

TLB reach is the amount of virtual memory that a TLB can cover without replacing entries.

In a simplified single-page-size TLB:

For 64 entries and 4 KiB pages:

If a loop repeatedly accesses a densely packed 128 KiB region, its translations can fit within that simplified reach. A loop that actively touches 8 MiB across many pages cannot keep every translation in a 64-entry TLB at once.

Real processors complicate the calculation:

TLB reach is therefore an upper-bound mental model, not a guarantee. It still provides a useful way to connect working-region size, page size, and translation pressure.

Larger pages let one TLB entry cover more bytes. That can increase reach for large, dense mappings, but larger page granularity has separate memory-waste and management tradeoffs.

A TLB must find a translation by content rather than by using the virtual page number as a direct array index into one enormous structure.

Small TLBs can behave like highly associative caches: hardware compares the requested virtual-page tag with several candidate entries in parallel.

A set-associative TLB divides entries into sets. Part of the virtual page number selects one set, and the remaining tag bits are compared with the entries in that set.

For a four-entry set:

The four candidate tags are compared in parallel, so associativity costs hardware rather than time.

Two frequently used virtual pages that select the same full set can repeatedly displace each other even when unused entries exist in other sets. This is a TLB conflict miss.

Processors often provide more than one translation cache:

The exact sizes, associativity, number of levels, and replacement behavior are processor-specific. Application code should not assume one universal organization.

A miss in the first-level TLB can still hit in a larger secondary TLB. Only after the available translation caches miss does the processor need a page-table walk on a hardware-managed design.

The virtual page number alone does not uniquely identify a translation. Process A and Process B can map the same virtual page to different physical frames.

A simple processor could flush user translations whenever it switches processes. Then no entry from the old process could be mistaken for an entry in the new process.

Flushing is safe but wasteful. If the scheduler soon returns to the original process, its useful translations must be loaded again.

Modern architectures commonly attach an address-space identifier to TLB entries:

For example:

Both entries can remain in the TLB without colliding logically.

The generic term is ASID. x86 uses a related mechanism called a process-context identifier, or PCID. Names and exact behavior vary by architecture.

The operating system assigns and manages these identifiers. Because the identifier space is finite, an identifier may eventually be reused. Before reusing it for an unrelated address space, the kernel must ensure that stale entries carrying the old meaning can no longer be used.

Address-space tags reduce the translation-cache cost of process switching. They do not eliminate every invalidation or guarantee that a process's entries remain cached; normal replacement can still evict them.

Threads in the same process share an address-space identity because they share page-table mappings.

The TLB is a cache. The process's page tables remain the authoritative mapping state.

Suppose a page table initially contains:

The CPU accesses the page and caches that translation in its TLB.

Later, the operating system changes the page table:

If the old TLB entry remains usable, the CPU could continue reaching frame 42 even though the page table says the mapping no longer exists. The cached entry is now stale.

Updating a page-table entry is therefore not enough. The kernel must also invalidate any cached translation whose meaning changed.

Mapping changes that can require invalidation include:

Adding a more permissive mapping can also require coordination. A stale restrictive entry may reject an operation that the new page table permits until the cache is refreshed.

The processor architecture supplies privileged invalidation operations. Depending on the change, the kernel may invalidate one virtual page, a range, one address-space context, or a broader set of entries.

TLBs are associated with CPU cores or hardware execution contexts, not stored as one system-wide software table.

Suppose two threads from one process run simultaneously on CPU 0 and CPU 1. Both CPUs cache:

CPU 0 enters the kernel and unmaps virtual page 10. It can update the page table and invalidate its own local TLB entry, but CPU 1 may still hold the old translation.

The kernel must arrange a TLB shootdown:

The request is commonly delivered using an interprocessor interrupt or an equivalent architecture mechanism. CPU 0 may need to wait until the relevant CPUs confirm that their stale translations are gone.

This ordering protects correctness. The kernel must not immediately reuse frame 42 for unrelated sensitive data while another CPU can still access it through a stale translation.

Shootdowns can be expensive because they coordinate CPUs and interrupt work running elsewhere. A kernel may batch invalidations, track which CPUs have used an address space, or apply architecture-specific optimizations to reduce the cost.

Applications normally trigger these costs indirectly through operations that create, remove, or change large numbers of mappings. Ordinary writes to existing mapped memory do not require a shootdown.

Switching between threads in one process does not change the address-space mappings, so their translations remain applicable.

Switching between different processes changes the virtual address-space context. The kernel must ensure that the incoming process cannot match translations belonging to the outgoing process.

Two broad strategies are:

Even with tags, a context switch can affect TLB performance. The incoming process's useful translations may already have been evicted by other activity, and different processes still compete for finite hardware capacity.

A transition from user mode to kernel mode does not inherently require flushing the entire TLB. The exact behavior depends on the operating system's mapping design, processor features, and security configuration. It is inaccurate to assume that every system call always destroys all cached translations.

TLB pressure matters most for workloads that repeatedly touch many pages:

Dense sequential access usually reuses one translation for many bytes. Random access across a much larger set of pages can produce more misses even when the total number of data accesses is the same.

Frequent mapping changes can create a different cost: invalidation and multicore shootdowns. A workload that repeatedly maps, unmaps, or changes permissions on large ranges can spend significant kernel and cross-CPU time maintaining translation consistency.

Linux perf can expose hardware TLB events when the processor and system permissions support them:

The event names mean:

Exact event definitions and availability vary by processor. Some systems report unsupported events or require elevated performance-monitoring permission. Raw counts should be interpreted alongside elapsed time, instruction count, CPU migrations, page size, and the workload's access pattern.

A miss count alone is not enough to diagnose slowness. The relevant questions are how frequently misses occur, whether they trigger inexpensive cached walks or expensive memory accesses, and whether translation work is material compared with the application's total execution time.

The TLB is a small hardware cache of virtual-page-to-physical-frame translations and their permissions. A TLB hit lets the processor form a physical address without walking the page table. A TLB miss triggers a lookup through lower translation caches or page tables; if a valid mapping is found, the result is cached and execution continues.

A TLB miss is not a page fault, and a TLB hit is not a data-cache hit. Translation caching and content caching solve different problems. TLB effectiveness depends on locality, reach, associativity, page size, and competition among active mappings.

Because the TLB is only a cache, page tables remain authoritative. When mappings or permissions change, the operating system must invalidate stale entries, including entries held by other CPUs through TLB shootdowns. Address-space tags such as ASIDs and PCIDs reduce unnecessary flushes while preserving process isolation.