The Linux 6.6 kernel ships with a new default scheduler[1]. Is the testing methodology in this paper relevant and used to assess the current (EEVDF) scheduler, or is it irrelevant?
I'd take a patch of CFS and its millions of broken knobs from Google over newly released EEVDF any day, because I trust scheduler AB testing by Google over millions of machines and every single scheduling pattern under the sun way more than whatever synthetic micro-benchmark a single kernel dev (as competent as they might be) ran.
If you're interested in quantitative analysis of schedulers & tooling around it, these 2 projects are very interesting:
https://github.com/google/schedviz
https://fuchsia.dev/fuchsia-src/concepts/kernel/fair_schedul...
I have nothing against the EEVDF algorithm itself (in fact I like it) and I dislike CFS very much. But I dislike the current development process of the Linux scheduler even more. Proper quantitative benchmarks of CPU schedulers are missing, which is why CFS ended in the sad state it did, where hundreds of patches were submitted to fix random edge cases over the years. What makes you confident that the initial EEVDF Linux implementation won't suffer the same fate, given that the development process hasn't changed (single kernel dev implementing it and running micro benchmarks)?
An increase in performance of 10-30% across "real" workloads. Just for changing one line (well, two lines including disabling p-state drivers)? I'll take it.
I would say its not a strange position to assume it has been improved further since then.
What would be interesting although niche is checking how iGPU's perform alongside it. I know that on Intel, "thermald" lowers iGPU performance because it improves CPU utilization and thus leaves less mW for the iGPU. Perhaps something similar will happen with EEVDF.