TLB Shootdowns and Cross-Core Translation Invalidation

18 Oct 2026 performanceoperating systems

A TLB shootdown is the coordinated interruption of CPU cores so they can discard cached address translations that became invalid after a page-table change. The operating system changes the mapping, tells other cores to invalidate their stale entries, and waits for their acknowledgments before treating the change as complete.

The problem: cached translations can outlive page-table changes

A program uses virtual addresses: addresses that describe the program’s private view of memory. Hardware translates each virtual address into a physical address, the location in RAM, using page tables maintained by the operating system. A page-table entry usually says which physical page corresponds to a virtual page and whether it is readable, writable, executable, or present at all.

Walking those tables for every load and store would be expensive. Each CPU core therefore keeps recently used translations in a translation lookaside buffer (TLB), a small cache that maps virtual-page numbers to physical-page numbers and permission bits.

The important detail is that TLBs are generally private to cores. Suppose a process is running on cores 0 and 1, and both cores have cached this mapping:

process virtual page 0x4000 -> physical page 0x9000, writable

The operating system then unmaps that virtual page, or changes it to point at a different physical page. It updates the page table in memory, but core 1 may still have the old translation in its TLB. A memory access on core 1 can therefore continue using the old mapping without consulting the newly changed page table.

That is not merely stale data. It can be a security and correctness failure: a supposedly unmapped page could remain accessible, a read-only page could remain writable, or a physical page could be returned to another process while a core can still access it through the old translation.

Why changing one page table affects other cores

The page table is shared state, but the cached translations are distributed state. Updating the shared page table does not automatically invalidate copies already held in each core’s TLB. Hardware needs an explicit invalidation operation for each relevant core.

A single-core system can usually perform that operation itself. On a multiprocessor system, the operating system must identify every core that might have used the affected address space and make each one invalidate its corresponding TLB entry. This is the “shootdown”: one core effectively interrupts the others and asks them to shoot down stale translations.

The operating system does not always need to contact every core in the machine. It tracks which CPUs are currently running a process or using its address-space identifier, and can target only those CPUs. Exact optimizations differ by processor architecture and operating system.

How the coordination works

The sequence is typically like this:

1. Change the page-table entry. The kernel removes a mapping, changes its permissions, replaces its physical-page address, or changes a larger range of mappings.
2. Determine the affected CPUs. The kernel builds a target set containing CPUs whose TLBs could contain translations for that address space and range.
3. Send an inter-processor interrupt. An inter-processor interrupt (IPI) is a hardware-supported interrupt sent from one CPU to another. The initiating CPU sends a TLB-invalidation request to each target CPU.
4. Run the target handler. When interrupted, each target CPU enters a small kernel handler. It invalidates the requested TLB entries, using an architecture-specific instruction or by reloading the address-space context. A single-page change may use an instruction such as INVLPG on x86; larger changes may use a broader flush.
5. Acknowledge completion. After invalidating its entries, the target CPU records or sends an acknowledgment. The initiating CPU waits until all required targets have completed.
6. Continue safely. Only after the required acknowledgments can the kernel safely assume that no targeted core will use the old translation.

The exact ordering matters. If the kernel freed the old physical page immediately after changing the page table, another core could still write through its stale writable TLB entry while that page was being reused. Waiting for the shootdown closes that window.

The page-table update and the invalidation request also require synchronization. CPUs must observe the new page-table state in an order that makes the invalidation meaningful; operating systems use locks, memory-ordering rules, and architecture-specific guarantees to arrange this. The TLB itself is not normally kept coherent by the cache-coherence protocol used for ordinary memory.

A shootdown is not a page-table update. It is the cross-core work required to make cached consequences of that update disappear.

Why shootdowns cost performance

An IPI interrupts another core, which may be running unrelated application code. The target must stop, enter the kernel, perform the invalidation, update coordination state, and resume. Meanwhile, the initiating core often waits for acknowledgments. On a machine with many cores, a frequently modified shared address space can turn this coordination into significant latency.

The invalidation itself has a second cost: future accesses may miss in the TLB and need fresh page-table walks. A large flush can therefore hurt performance after the shootdown has finished, even if the interrupt was quick.

Operating systems reduce this cost in several ways:

• Batching: combine several page changes into one invalidation request.
• Target filtering: interrupt only CPUs that could have cached the address space.
• Range-aware invalidation: invalidate a small range instead of flushing everything when the architecture supports it efficiently.
• Address-space tags: features such as x86 PCIDs and Arm ASIDs label translations by address space, reducing unnecessary flushes when switching processes. They do not eliminate the need to invalidate a changed mapping.
• Deferred work: in cases where it is safe, postpone reclamation or invalidation until a CPU leaves the address space rather than interrupting it immediately.

Where you may have seen it

The term often appears in performance profiles, kernel tracepoints, and discussions of virtual-machine or database latency. High rates can follow workloads that repeatedly change mappings: creating and destroying processes, changing memory protections, unmapping large regions, or managing many threads across many CPUs.

A TLB shootdown is therefore best understood as a consistency protocol for hardware translation caches. The page table is the authoritative mapping, but the operating system must interrupt and hear from other cores before it can rely on that authority everywhere.