Revisiting The Linux 6.19 Performance With "NEXT_BUDDY" Now Disabled
Back at the start of the Linux 6.19 kernel cycle I ran benchmarks showing some scheduler performance regressions with the new kernel. Fortunately, two weeks out from the Linux 6.19 stable release, merged this weekend was 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.
The NEXT_BUDDY feature that was adapted to EEVDF and enabled back during the Linux 6.19 merge window is 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.