This morning I drew attention to some ongoing work surrounding a 20-year-old chipset solution in the Linux kernel that had harmed modern AMD systems by mistakenly still applying the change to modern hardware. Fortunately, that patch has now been picked up by Linus Torvalds, in time for the Linux 6.0 kernel expected for its stable debut next weekend.
As explained in that earlier article, since 2002 when ACPI support was added to the kernel, a “dummy wait” operation has been added due to some chipsets when STPCLK# was not acknowledged in time along the inactive path in the kernel. The dummy I/O read delays further instruction processing until the CPU has completely stopped. But an AMD engineer recently noticed that this behavior is being applied to modern AMD Zen 3 hardware and found that it can lead to performance issues for workloads that switch quickly between busy and idle phases and especially for larger core count systems like Ryzen Threadripper and EPYC. platforms.
Sampling certain workloads with IBS on the AMD Zen3 system shows that a significant amount of time is spent in the dummy operation, which is erroneously counted as C-State residency. A high C-State residency value may prompt the cpuidle governor to recommend a deeper C-State during subsequent inactive instances, creating a vicious cycle leading to performance degradation on workloads that quickly switch between busy and busy. inactive phases.
One such workload is tbench where a huge performance drop can be observed during certain runs.
AMD engineer K Prateek Nayak demonstrated the significant performance impact this flawed modern hardware solution can have on AMD systems. Intel systems meanwhile do not use this code path for modern hardware and so are untouched.
An AMD patch was originally proposed but then cleaned up/simplified by Intel engineer Dave Hansen. That patch just doesn’t apply this “dummy wait” solution, except for older (pre-Nehalem) Intel systems and so AMD systems will now forgo this operation that can reduce performance on modern systems. Since it mainly affects workloads that frequently switch between busy and idle states plus more noticeably for systems with a higher core count, AMD EPYC server performance with this patch should be quite interesting especially for web server/database workloads and other quick type tests. I will launch a full set of broad benchmarks tomorrow to evaluate this patch.
The patch has been mainlined tonight as part of the “x86/urgent” fixes shipped as part of this pull ahead of the expected stable release of Linux 6.0 on October 2nd. Great to see it landing fast and stay tuned for some benchmarks.
Supply hyperlink