Some kernel updates can't be done incrementally. Patching a function that every CPU might be executing right now, swapping a data structure that has no RCU-safe pointer, or updating CPU microcode — all require a moment where nothing else is running. That moment is what stop_machine() creates.

The mechanism. Each CPU has a dedicated high-priority kernel thread called migration/N (visible in ps). These threads sit at SCHED_FIFO priority 99 — higher than any user task, higher than nearly any kernel thread. When you call stop_machine(fn, data, cpumask), the kernel wakes up the migration thread on each targeted CPU. Because of their priority, they preempt whatever is running — kernel or user, RT or normal — almost immediately.

Each thread then spins on a shared atomic counter waiting for all its peers to arrive. Only when every CPU has checked in does one designated CPU execute fn(data). The others sit in the spin loop with interrupts disabled. When fn returns, they all release and resume normal scheduling.

Real-world uses:

• CPU hotplug: Taking a CPU offline requires guaranteeing no one is running on it — stop_machine() makes that trivial.
• ftrace patching: When you enable a tracer, the kernel rewrites the first bytes of thousands of functions (replacing NOPs with a call to the trace handler). stop_machine() ensures no CPU is mid-decode when the bytes flip.
• Module unloading (older kernels): Used to guarantee no CPU was executing inside the module.
• Microcode updates: Some updates require every core quiesced before the write.
• Text_poke on older x86: Cross-modifying code needed all cores stopped to avoid the SMC pipeline detecting a partial write.

The cost. Rule of thumb: stop_machine() takes roughly 10–100 microseconds per CPU in the best case, but scales poorly. On a 128-core server, the barrier synchronization alone can push a single invocation past 1 millisecond. Every CPU is idle during that time — that's 128 core-milliseconds of throughput vaporized per call. Facebook and Google engineers have documented cases where frequent stop_machine() calls (e.g. from repeatedly toggling static keys or ftrace) caused visible tail-latency spikes in production services.

Escaping it. Modern kernels work hard to avoid stop_machine(). Static keys use text_poke_bp (patching via an INT3 trap so other CPUs stumble harmlessly through the transition). RCU replaces the "wait for everyone" pattern with "wait for everyone to voluntarily reach a quiescent state." Both trade complexity for the ability to update global state without stopping the world.