Rust-Written Linux Scheduler Showing Promising Results for Gaming Performance

Are we at this level now? The scheduler performance has nothing to do with the used language. Actually making use of the freedom C provides (while being unsafe) you have the ability to implement whatever complex algorithm you can envision in the most direct way. Moreover scheduling is all about tradeoffs: it's not hard to write a scheduler that is better than a genera purpose one for a specific task. If you like Rust write your code in Rust but the community should stop with this kind of attitude.

&quot;I ended up writing a Linux scheduler in Rust using sched-ext during Christmas break, just for fun. I&#x27;m pretty shocked to see that it doesn&#x27;t just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming).&quot; — Andrea Righi<p>I think that pretty clearly summarizes the entire reason for doing this and the excitement that it works and works well.

You can swap out the scheduler dynamically using eBPF!? That&#x27;s incredible.

I would like to stem a little bit of sentiment here.<p>I can write a toy program that saves files to disk much faster than notepad.exe, but this is a consequence of making fewer decisions and handling fewer edge cases.<p>It&#x27;s trivial to make fast software, especially toy software, but they tend not to survive practical applications without becoming as slow or slower than the systems they originally mimic.<p>That said: that it works is really cool.

I think the important bit here is: a Linux scheduler written &quot;during Christmas break, just for fun&quot;, is better that the current one. it might be the developer sense of &quot;fun&quot;, it might be rust, but it is impressive, notheless

That such a simple 2D game isn&#x27;t able to reach 60fps under heavy system load just shows that the vanilla scheduler doesn&#x27;t boost the process associated with the currently active window though?<p>Shouldn&#x27;t this be standard on all &#x27;desktop&#x27; operating systems, e.g. anything associated with the user gets higher priority than anything else happening on the system? Even the Amiga had such a priority-boosting system back in 1985 (otherwise multitasking wouldn&#x27;t be of much use on such a slow computer, because pretty much any background task would make the UI unusable).

Had this scheduler not been written in Rust, would it still have ended up on HN?

&gt; For production scenarios, other schedulers are likely to exhibit better performance, as offloading all scheduling decisions to user-space comes with a certain cost.<p>Aside from possibly increased scheduler latency, there’s the rather larger potential cost of outright deadlocks: what guarantees that the user scheduler task runs at all when it’s needed?<p>On 60 seconds of skimming the repo, I didn’t spot a specific solution to this problem. I wonder how it was addressed. Or maybe it wasn’t, since this is just an experiment.

What is the implication here, or what is it trying to say? If it outperforms C, then it obviously has very different implementation details, including algorithms and whatnot. It does not outperform the scheduler because it is written in Rust.

Highly doubt subpar Linux gaming experience is due to its scheduler implementation.