A page-table entry can change in memory while another CPU still holds the old address translation in its translation lookaside buffer (TLB). Updating the page table alone therefore does not necessarily make the new mapping effective on every processor that has executed the affected address space.
Operating systems close that gap with TLB invalidation. When a mapping change can make a cached translation unsafe, processors that may retain the translation must invalidate it before the kernel treats the change as globally complete. On a multiprocessor system, coordinating those remote invalidations is commonly called a TLB shootdown.
The mechanism is a correctness boundary, not merely a cache optimization. A stale translation can refer to a physical page that has been unmapped, recycled, assigned different permissions, or repurposed for another mapping.
The TLB is separate from the page table
Virtual-memory translation normally begins from page tables maintained in memory, but processors avoid walking those tables for every memory reference. A TLB caches recently used translation information close to the execution pipeline.
That cache creates two distinct states:
page tables in memory
|
| page-table walk
v
cached TLB translation
|
v
memory accessChanging the page-table entry updates the first state. It does not, by itself, guarantee immediate removal of every matching entry from processor translation caches.
Architectures provide explicit invalidation mechanisms for this reason. The exact instructions and scope differ by architecture. An operating system must follow the architecture’s required ordering and invalidation rules rather than treating a page-table store as sufficient synchronization.
A stale translation can outlive an unmap
Consider two CPUs running threads from the same process. CPU 0 and CPU 1 have both accessed virtual page V, so both may cache a translation from V to physical page P.
CPU 0 TLB: V -> P
CPU 1 TLB: V -> P
page table: V -> PCPU 0 then enters the kernel and removes the mapping:
page table: V -> not presentCPU 1 may still have V -> P in its TLB. If the architecture permits that cached entry to satisfy another access, CPU 1 can continue using P until the entry is invalidated or otherwise displaced.
The risk becomes more serious if the kernel makes P available for reuse before remote invalidation is complete. The physical page could acquire a different purpose while CPU 1 still has a translation that reaches it. Correct reclamation therefore has to respect the invalidation protocol.
Permission changes have a similar issue. Removing write permission from a page-table entry is not sufficient if another processor can still use a cached writable translation. The required invalidation ensures that subsequent accesses are checked against the updated mapping state.
Local invalidation does not clear remote TLBs
A CPU can invalidate its own translation entries with architecture-specific operations, but another CPU has separate translation-cache state. One processor cannot assume that a local invalidation has changed a remote processor’s TLB.
A typical shootdown sequence has this shape:
CPU 0 CPU 1
change page table
record invalidation range
send cross-CPU request ----> receive request
invalidate matching TLB state
wait for completion <---- acknowledge completion
continue reclamationThis is a conceptual sequence rather than a universal implementation. Kernels can batch ranges, use per-address-space tracking, defer work under permitted conditions, or choose broader invalidations when that is cheaper than many narrow operations.
The important property is completion: any CPU that could legally retain an unsafe stale translation must reach a state in which that translation can no longer be used before dependent reclamation or protection changes proceed.
Cross-CPU coordination adds a scalability cost
A local TLB invalidation already disturbs cached translation state. A remote shootdown adds coordination between processors. The initiating CPU may need to identify relevant processors, issue inter-processor notifications, and wait until remote invalidation has completed.
The cost is workload- and machine-dependent. It varies with processor architecture, kernel implementation, CPU count, address-space placement, invalidation range, and the amount of translation state discarded. There is no single latency value that applies to all systems.
The scaling concern comes from synchronization. A mapping change that requires action on many CPUs can create more cross-CPU work than a change confined to one processor. Frequent mmap, munmap, protection changes, allocator activity, or page reclamation can therefore interact with TLB invalidation overhead, but the actual effect must be measured on the target system.
A broad invalidation can also evict translations unrelated to the one entry that motivated the operation. Those translations may later require fresh page-table walks. Narrow invalidation preserves more TLB state but can require more invalidation operations. Kernels and architectures expose different trade-offs between these choices.
CPU tracking can limit the shootdown set
An address space is not necessarily active on every CPU. Kernels can track which processors currently run, or have recently run, a given address space and use that information to avoid sending invalidation work to processors that cannot hold relevant translations.
This optimization depends on correct bookkeeping. If a processor can retain translations for an address space after switching away from it, the kernel must account for that possibility according to the architecture and the address-space tagging scheme.
Tagged TLB designs make this more flexible. Identifiers such as x86 PCIDs or Arm ASIDs allow translations from multiple address spaces to coexist without requiring a complete TLB flush at every context switch. Tags reduce unnecessary invalidation, but they do not eliminate the need to invalidate entries when the mapping represented by a valid tag changes.
Tag reuse also needs control. Reassigning an identifier while old translations carrying that identifier remain usable could make stale state appear to belong to the new address space. Operating systems coordinate identifier lifecycle with the architecture’s invalidation facilities.
Batching changes can reduce synchronization frequency
Several page-table updates can sometimes share one invalidation phase. Instead of forcing a remote synchronization after every individual entry change, a kernel can collect an affected range or set of ranges and invalidate them together when correctness permits.
Batching does not remove the ordering requirement. Physical pages or old permissions cannot be treated as safely retired before all required invalidations associated with those changes have completed.
The benefit is fewer coordination events. This matters in operations that modify many mappings, such as tearing down a large region or changing protection across multiple pages. The exact batching policy is an operating-system implementation choice and can change independently of the processor’s architectural rules.
Huge pages change invalidation granularity
A TLB entry can represent more than a base-size page. Huge-page mappings cover larger virtual ranges, so replacing, splitting, or changing such a mapping affects translation state at a different granularity.
The operating system must invalidate every cached translation that can represent the old mapping. Depending on the architecture and operation, that can require invalidating a range, invalidating entries at multiple page sizes, or using a broader context-level operation.
This is another reason page-table structure and TLB state cannot be treated as identical. A software-visible page-table edit may correspond to cached hardware translations with architecture-specific representation and granularity.
Shootdowns protect the boundary between mapping change and reuse
The central constraint is temporal. Page-table memory can contain the new state before every processor has stopped using the old state.
A safe sequence establishes a boundary between those phases:
publish new page-table state
|
required ordering
|
invalidate relevant translations
|
confirm required CPUs completed invalidation
|
reuse page or rely on new permissionsDetails vary across processor families and operating systems, but the invariant remains: stale translations that could violate the new mapping state cannot remain usable past the point where the kernel depends on that state.
That invariant is what turns a page-table update from a local memory write into a multiprocessor synchronization event.