I think the important bit here is: a Linux scheduler written "during Christmas break, just for fun", is better that the current one.
it might be the developer sense of "fun", it might be rust, but it is impressive, notheless
> a Linux scheduler written "during Christmas break, just for fun", is better that the current one.
...with certain workloads
i.e. it might be a bit better in a few specific cases, but a bit worse in a large number of more common workloads.
Not that I'm trying to take anything away from the work - getting on par with the well-tuned-over-many-years scheduler for any workloads is an impressive feat. But saying it's "better than the current one" without the caveats made by the original author is oversimplifying to the point of being misleading, I think.
given the video literally showcases how to change the scheduler at runtime while the game is running, it's actually great. imagine Steam loading a new scheduler when a game starts? this way we could all the time run the best scheduler for the workload without issue.
...is better for one specific workload scenario. It's actually baffling that the default scheduler doesn't seem to boost the priority of the 'active window process'.
The linux kernel has no concept of "active window process". It has the concept of "current process", and deciding which process that is, is exactly the job of the scheduler. :P
I'd love to see more focus on this in the Linux scheduler, at least allowing an optional mode for interactive use. It's frustrating to have my entire system occasionally grind to a halt because of compilation or a particularly beefy test suite.
That's what (in)famous kernel dev Con Kolivas[1] was doing up to late noughties. I'm not sure if he's still active in maintaining out of tree schedulers though.
...with certain workloads
i.e. it might be a bit better in a few specific cases, but a bit worse in a large number of more common workloads.
Not that I'm trying to take anything away from the work - getting on par with the well-tuned-over-many-years scheduler for any workloads is an impressive feat. But saying it's "better than the current one" without the caveats made by the original author is oversimplifying to the point of being misleading, I think.