The solution
When ACPI support was added to the Linux kernel in 2002 — written by Andy Grover, committed by Linus Torvalds — it included a 'dummy wait op': the system read data for no purpose other than delaying the next instruction until the CPU could fully stop with the STPCLK# command. That bought power savings and compatibility in the early days, when some chipsets refused to enter idle states as expected.
Twenty years later AMD engineer Prateek Nayak submitted a kernel patch to 'skip dummy wait for processors based on the Zen microarchitecture'. Modern Zen chips need no such nudge, and testing with instruction-based sampling showed the dummy op still consumed significant time that the kernel incorrectly accounted as C-state residency. Seeing all that low-effort work, the CPU pushed itself into deeper, slower C-states, then took longer to wake — hurting jobs that switch constantly between busy and idle.
The measurements were dramatic: in tbench runs on a dual-socket Zen3 system, the patched kernel delivered a 1,390% increase in minimum MB/s throughput and a 51% increase in mean MB/s over the baseline kernel, landing close to the result of disabling the C2 sleep state entirely.
Intel systems had dodged the legacy curse for a decade thanks to an MWAIT-based idle mechanism, and Intel's Dave Hansen submitted an urgent patch limiting the dummy wait to Intel systems — where it would not affect 'remotely modern' machines — plus comments urging readers to move to more modern idle mechanisms. Submitted in time, the fix could make the Linux 6.0 kernel shipping the following week.
Why it worked
The diagnosis is the genius: instruction-based sampling revealed that wasted time was being mislabelled as healthy sleep, turning a power-management accounting bug into a visible performance cliff.
The fix costs one branch — skip the dummy wait on Zen — yet recovers fourteenfold minimum throughput, a ratio rarely achievable by any optimization of real work.
It is a live specimen of technical debt: code added for 2002 chipsets survived two decades and multiple CPU generations because nothing ever failed, it just got slower.
What can be applied
Compatibility shims outlive the hardware they serve: unless someone re-audits them against new silicon, a 20-year-old no-op can become an invisible tax that looks like a chip problem.
Aftermath
Nayak's Zen patch and Hansen's urgent follow-up limiting the dummy wait to Intel systems were submitted in late September 2022, in time for consideration in the Linux 6.0 kernel Torvalds expected to ship the following week. Intel's patch also added comments encouraging migration to modern idle mechanisms. Ars Technica reported no residual issues for AMD systems once the patch landed.
FOLLOW THE EVIDENCE
The sources
- 20-year-old Linux workaround is still slowing down AMD systems arstechnica.com