Back at the start of the [1]Linux 6.19 kernel cycle I ran benchmarks showing [2]some scheduler performance regressions with the new kernel . Fortunately, two weeks out from the Linux 6.19 stable release, merged this weekend was [3]disabling the scheduler's NEXT_BUDDY feature due to performance regressions . Here are some fresh benchmarks looking at the latest Linux 6.19 Git state with/without NEXT_BUDDY and comparing it to Linux 6.18 stable for reference.

[4]

The [5]NEXT_BUDDY feature that was adapted to EEVDF and enabled back during the Linux 6.19 merge window is [6]now disabled in Linux 6.19-rc7 due to reported performance regressions in MySQL, SPECjbb, and DayTrader. With some of my Linux 6.19 regressions published in early December tracing back to the NEXT_BUDDY commit as a possible culprit during the Git bisect, over the weekend I ran some all-new benchmarks to see the impact of this late disabling of NEXT_BUDDY in Linux 6.19.

On the same AMD Ryzen Threadripper PRO 9995WX workstation, the following kernel combinations were tested:

v6.18 - The stable Linux 6.18 LTS kernel release.

Linux 6.19 Git 23 Jan - The Linux 6.19 Git state as of Friday night and using the same Kconfig as v6.18 and with all new v6.19 kernel options at their defaults.

No NEXT_BUDDY - The same Linux 6.19 Git state as above but disabling NEXT_BUDDY as done in the patch that was merged this weekend ahead of v6.19-rc7.

From there a wide variety of benchmarks were conducted for seeing the impact of NEXT_BUDDY, given that there was believed to be some performance benefits when the code originally was merged but now clearly being responsible for some regressions too.



[1] https://www.phoronix.com/search/Linux+6.19

[2] https://www.phoronix.com/review/linux-619-sched-regress

[3] https://www.phoronix.com/news/Linux-6.19-Disabling-Next-Buddy

[4] https://www.phoronix.com/image-viewer.php?id=linux-619-next-buddy&image=next_buddy_lrg

[5] https://www.phoronix.com/search/NEXT_BUDDY

[6] https://www.phoronix.com/news/Linux-6.19-rc7-Released