Linus Torvalds’ internet and electricity went out due to a blizzard, and his new Linux 6.8 code suffered performance degradation that affected his Linux kernel build before impacting the Linux 6.8 merge window, causing his weekend to be cut short. was already in a bad state. It will be twice as long as the previous kernel. It is believed that AMD Linux engineers have been able to reproduce the regression and are working with upstream developers to fix this issue in the latest scheduler code.
In discussing the significant performance degradation reported by Linus Torvalds due to scheduler changes in Linux 6.8, it was not immediately clear to developers what was causing the degradation when it came to binary commits. In a subsequent discussion, AMD’s Wyes Karny said: report He thought he might be able to recreate the regression. Rather than his high-end AMD Ryzen Threadripper like Torvalds used, Wyes was using his modest AMD Ryzen 5600G desktop. One of the important notes he mentioned was that this only reproduced if he disabled his ACPI CPPC from his BIOS and in the Schedutil governor he used ACPI CPUFreq.
Most AMD Zen 2 and newer systems support ACPI CPPC, so the latest kernels on the Ryzen side typically use the new AMD P-State driver. However, some Zen 2 / Zen 3 systems (or those that disable CPPC from the BIOS) still use the CPUFreq driver, and the default CPU frequency governor is typically a “Schedutil” driver to leverage scheduler utilization data. “is.
A thread on that mailing list suggested patches and discussed specific issues with this regression. Eventually, Vincent Guittot was convinced that he could fix the regression, and Wyes successfully tested the patch.
Sent by Guittot sched/fair: fix frequency selection in constant case As a patch to fix a nasty regression in new Linux 6.8 code when using ACPI CPUFreq + Schedutil. He describes the patch as follows:
“If frequency invariance is not enabled, get_capacity_ref_freq(policy) returns the current frequency and the performance margin applied by map_util_perf(). You will also be able to select higher frequencies.
Performance margins are now applied early in the path to account for some utilization limits, preventing you from getting more utilization than your maximum computing power.
To have the opportunity to select a higher OPP when the current OPP becomes fully used, you must use a higher frequency than the current frequency. Apply the same margin and return a frequency 25% higher than the current frequency in order to switch to the next OPP before fully using the current CPU. ”
Ultimately, it was a one-line code fix that addressed this performance drop that caused Linus Torvalds’ empty kernel build to go from 22 seconds to 44 seconds.
Assuming everything continues to test well with the new patch, the fix should be applied to the Linux 6.8 Git code once Linus Torvalds’ internet and electricity are restored.