When you munmap() a page or the kernel remaps something, the page table in memory changes instantly — but every core in the system has its own private TLB caching stale translations. The hardware has no coherence protocol for TLB entries the way it does for cache lines. Someone has to actively tell each core: throw away that translation. That someone is software, and the mechanism is called a TLB shootdown.

Here's the ugly dance the kernel performs:

• Core 0 modifies a page table entry (say, marking a page as unmapped).
• Core 0 invalidates its own TLB entry with INVLPG (x86) or tlbi (ARM).
• Core 0 sends an Inter-Processor Interrupt (IPI) to every other core that could have cached that translation.
• Each target core takes the interrupt, executes its own INVLPG, and sends an acknowledgment.
• Core 0 spins waiting for all acks before it can safely reuse the physical page.

This costs 1,000–20,000 cycles depending on core count. On a 64-core server, a single unmap can stall every core simultaneously. Contrast with cache coherence, which happens in hardware in tens of cycles — TLBs are shot down in software because building coherent TLBs would require broadcasting every page-table write across the interconnect, and page tables change constantly during process teardown.

Real-world example: A Redis instance handling millions of small allocations was periodically freezing for 2ms bursts. The culprit was glibc's madvise(MADV_DONTNEED) returning pages to the kernel, triggering shootdowns across all 96 cores of the socket. Switching to jemalloc with retained pages eliminated the storms. Similarly, JVM garbage collectors that unmap regions can cause application-wide latency spikes correlated with core count.

Hardware has been slowly clawing this back. ARM's TLBI broadcast instruction sends invalidations across the interconnect without IPIs — the receiving cores handle them silently. Intel added INVPCID for more selective flushing, and PCIDs let context switches skip flushes entirely. AMD's Broadcast TLB Invalidate (announced for Zen 5) finally brings ARM-style behavior to x86.

Rule of thumb: Shootdown cost scales roughly as O(N) with core count on x86, and each shootdown costs about 200 + 100×N cycles on a modern Xeon. A 64-core shootdown ≈ 6,600 cycles ≈ 2μs. Do 500 of those per second and you've burned 1ms of every core's time on nothing.

The practical implication: batch your unmaps. Unmapping 1,000 pages in one syscall triggers one shootdown; unmapping them one at a time triggers 1,000.