Investigating Split Locks on x86-64

What are split locks and why care?

Chester Lam at Chips & Cheese has a clear answer: they are bad. Split locks are atomic operations that straddle a cache-line boundary, forcing CPUs to fall back from fast per-line cache coherency to a much heavier locking mechanism. It has been reported that Intel and AMD apparently don’t have hardware that can lock two cache lines at once, and so the core resorts to a "bus lock." That fallback is allegedly loud — a noisy-neighbor event that can drag system-wide performance down hard.

The test and the teeth-grinding numbers

Lam’s microbench uses a looped lock cmpxchg (via _InterlockedCompareExchange64) moved to straddle a 64‑byte cache line. The result? Latency explodes. On Intel Arrow Lake, split locks pushed core-to-core latency to about 7 microseconds; on a Zen 5 part the worst case was around 500 ns — both orders of magnitude slower than normal. Split locks hit L2 first and can halve memory performance beyond that; some workloads (Geekbench 6 photo filter) suffer badly, while others (asset compression) are less affected. In short: a single badly aligned atomic can make a machine miserable.

Mitigation, and the medicine problem

Modern chips can trap split-lock events so kernels can detect the offender. It has been reported that Linux now defaults to this trapping and even injects an artificial delay as a mitigation to tamp down the noisy-neighbor effect. But that raises an awkward question: fix the bug in the app, or punish everyone with added latency? The mitigation helps noisy systems, yes — but the cure is blunt. Align your atomics. Recompile. Audit code generated by compilers or JITs. The issue is small in code size but big in impact.

So what now?

This is a reminder: low-level alignment still matters. In cloud and multitenant environments, one misaligned atomic from a noisy VM can ripple outward. For sysadmins and compiler writers: add tests, enable traps, and push developers to avoid split locks. For everyone else: if your performance mysteriously tanks, ask whether an 8‑byte value is sitting half in one cache line and half in the next. It’s the kind of tiny mistake that makes hardware scream — and one we can actually fix.

Sources: chipsandcheese.com, Hacker News