For those getting excited, It doesn't "boost" gaming performance. It prioritizes the game over the background process (in this case, a kernel being compiled.)
Schedulers aren't magic. As pointed out in the comments of the linked article, there are other ways of doing this. The more interesting tech here is being able to choose between schedulers under specific workloads, which is very nice IMO.
Schedulers aren't magic, but there are mores ways to skin a cat.
I think process schedulers is a neat and easy compartmentalisation of a concept in itself that adheres to the UNIX philosophy. Hey, if new hardware with new instructions come, that old scheduler might not be the best fit anymore (x86 went big.LITTLE), or say you got a particular workload that works well with a specific scheduler - the latter possibly being a myth.
I've rarely met anyone who didn't stick to their distributions of choice. This is because recompiling the kernels all the time is a pain and crufting up your system with third party repos is just added complexity.
Jokes on you though, that's why I run NixOS. it's all cruft and complexity lol
I looked into this a bit more and here is the summary: This is meant to show off a candidate kernel feature that allows for running different schedulers in userland.
Task scheduling has become much more complex as CPUs have grown in size and have had new developments in architecture, so the need to develop more complex and robust schedulers is steadily rising.
The kernel feature is meant to lower the barrier of entry for anyone who wants to try getting into schedulers, as well as enable quicker development iteration, by removing the need to completely recompile the linux kernel every time you want to test your code.
Not quite running in userspace. To the best of my own understanding:
The new kernel feature is to allow writing schedulers in eBPF, a "language" the kernel runs in kernelspace that is heavily restricted.
For example, all eBPF programs must complete in bounded time, and the kernel's static checker must be able to verify that before the program can even begin executing. eBPF is a rare language that is not touring complete.
"For scx_simple, suspending the scheduler process doesn't affect scheduling behavior because all that the userspace component does is print statistics. This doesn't hold for all schedulers."
So, it may be that eBPF also makes it easier to write a truly userspace scheduler, but that's not the primary purpose, and it's not what is being done with scx_simple.
Wow, that's a huge difference. I wonder if it's just a niche case that fixes Terraria specifically, it would be nice to see more benchmarks on other games.
I didn't watch it all. (OK, didn't realize it was only a minute. I basically saw everything).
But I wonder if it's simpler than that, and it's just doing a better job prioritizing the game. Presumably there's a reason they're doing it while running a heavy background process.
This obviously still has value if it's the case, and is a big part of the point of a scheduler, but the headline implied (to me) that it's a general performance improvement, and the video doesn't demonstrate that.
I'm not 100% sure, I just assumed you could affect power use too with different schedulers. Either way, even if that's not the case, being able to change the performance characteristics based on what you want to do on the fly is pretty exciting in its own right.
A governor guides the hardware regarding power consumption, but it is still dependent on workload and utilisation. Moreover, modern p-state drivers may use utilisation to control voltage and frequency scaling and there is also a scheduler driven governor in Linux (actually it's the most recent one iirc).