Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS

[natunobilis]

/me waits for people to complain about the fact that this is based on a research paper from the 90's

I'm not an academic but I have scientific training, and I would find it surprising if the field of CPU scheduling algorithms (or whatever it's academically called) has not seen any improvement since 1996 that would be worth implementing in Linux.

So I won't complain but I'll take the bait and ask, for my own education: isn't there anything newer and potentially more promising than a 1996 algorithm?

[jacob]

/me waits for people to complain about the fact that this is based on a research paper from the 90's

I'm waiting for people to complain that there was nothing wrong with the 1972 Unix scheduler. Surely this must be part of the overarching systemd/wayland/rust/ipv6 conspiracy!

[timofonic]

If you use the "default" BORE Scheduler, you are also using "two" schedulers with CFS. BORE does not replace the complete base scheduling modell, it does enhance it.
Since the BORE developer is in our team, we started very early to adjust BORE to EEVDF.

You can find it in our kernel-patches directory.

In my eyes it is not really smart to replace a complete scheduler, like PDS/BMQ does since the CFS/EEVDF Scheduler gets way more tested against many hardware and other regressions. So improving the scheduling for desktops is just a better idea.

Is BORE better for desktop systems or similar? What about merging upstream?

[freerunner]

Benchmarks?

Merge summary:

https://imgur.com/a/YlWGXCP

Some stressng runs, quick and dirty.
Individual run data should be somewhere around openbenchmarking.org (prefix kernel-*-stressng)

[Errinwright]

In terms of throughput there won't be much difference. A bunch from your mentioned schedulers are nowadays not well maintained anymore.
TT gets rarely updates and I just port it over and over to every new kernel version.
PDS/BMQ has a lot of bugs. May he will rewrite it soon, who knows, but it its current state it is often not really use able and the performance improvement as it was some years ago, when CFS was not really fine for desktops.

Anyways, the developer of the BORE scheduler made a little graph, with the tool from Julia, which is the creator of the "NEST" Scheduling.
Here the link:

https://gitlab.inria.fr/schedgraph/schedgraph/-/tree/main

The graph comparison in scheduler characteristics. BORE, CFS, EEVDF and the BORE-EEVDF variant got there compared. This was on a 5800X.

https://imgur.com/a/ByXpvuW

On CachyOS with the default kernel we use nowadays the "eevdf-bore" variant, since it does improve the heavy load responsives and still provides the latency enhancements from EEVDF. Also we use the latency nice interface really much together with our ananicy-cpp and its rules.

Looking forward that this gets merged, using it since around 2 months and love it.

Out of curiosity, why does the graph not include some form of NEST scheduler testing, with or without, EEVDF/BORE?

[ptr1337]

Out of curiosity, why does the graph not include some form of NEST scheduler testing, with or without, EEVDF/BORE?

Sorry for the late response, was not logged in since a while here.
NEST is basically "dead". We tried to kept it alive, but the initial version did already not boot, but we fixed it.

With further upstream changes, NEST was completly broken and we did not rebased it.
Maybe Julia will rebase it someday, we are following here gitlab.

[Errinwright]

Sorry for the late response, was not logged in since a while here.
NEST is basically "dead". We tried to kept it alive, but the initial version did already not boot, but we fixed it.

With further upstream changes, NEST was completly broken and we did not rebased it.
Maybe Julia will rebase it someday, we are following here gitlab.

Thanks for the information. Based upon your experience with it thus far: do you expect it to be beneficial in the future for low core count (desktop parts) in gaming scenarios?