- cross-posted to:
- pcgaming@lemmy.ca
- cross-posted to:
- pcgaming@lemmy.ca
tl;dr large gaming performance over stock CPU scheduler when there is a heavy CPU task running in background
Obviously, they only tested one game and it may not apply everywhere or hurt performance/latency in some cases.
One thing I wasn’t aware of is that sched-ext/ePBF supports changing CPU schedulers on-the-fly, which takes away one of the downsides of third-party schedulers. I.e. you can use the stock scheduler most of the time, but then switch to a third party scheduler for specific workloads. So less of a downside risk.
Finally, none of this is merged yet (including sched-ext) so it’s out of reach if you are just using the stock kernel.
It’s nice that we could see more rust in the kernel beyond drivers.
Though looking at his code/documentation, it seems that the big win here is moreso giving higher time-slice values to applications that identify themselves as “interactive”.
This is a similar concept to what I’ve seen happen in MacOS, where even running unit tests for my work application doesn’t bog down the rest of the system. In windows, however, a single heavy process can bring the whole system down to a crawl.
Rust does have the benefit of being 1. safer on memory (though it uses unsafe blocks here) and 2. a lot easier to parse compared to (imo) archaic versions of C. Even this hobby project has some pretty impressive readability compared to some parts of the kernel that I’ve tried to read for the fun of it.