Originally posted by Britoid
View Post
Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance
Collapse
X
-
Originally posted by bug77 View Post
Presumably, if run from the terminal. But that's not the only way to run make. In particular, a build pipeline will probably not fire up a terminal to invoke make.
but ofcourse this does not apply to a kernel build when using make in /usr/src/linux.
several things here, desktops dont use/set scheduler/cgroup information properly, as someone stated before on windows its done properly. And secondly background tasks are not set properly either as background tasks. The thing is the terminal(if called from a terminal) might not be a background task, you want the terminal to be responsive, but it could be a foreground task if thats your GUI. So if you call make and make doesnt use cgroup or any scheduling at all you are boned.Last edited by cj.wijtmans; 17 January 2024, 10:03 AM.
Comment
-
-
Originally posted by cj.wijtmans View Post
on gentoo the scheduler can be set on idle and it uses cgroup.
but ofcourse this does not apply to a kernel build when using make in /usr/src/linux.
several things here, desktops dont use/set scheduler/cgroup information properly, as someone stated before on windows its done properly. And secondly background tasks are not set properly either as background tasks. The thing is the terminal(if called from a terminal) might not be a background task, you want the terminal to be responsive, but it could be a foreground task if thats your GUI. So if you call make and make doesnt use cgroup or any scheduling at all you are boned.
Everything that gets spawned (by terminal etc) but has no user interaction should run at normal priority. Even better would be a small interface that lets you decide if something needs higher priority and runs this as desired in all future starts.
Also real time stuff like video, audio, 3D games should always have an extra priority class for RT stuff (low latency).
It's just hard to fully automate this so package maintainers would have to tag their stuff manually.
Comment
-
-
cj.wijtmans If we're lucky, Intel's heterogeneous CPUs will push more people into taking another look at scheduling.
Even though Win11 was touted to be the first OS to have proper support for those, it was still tripping on this very scenario: start whatever high-priority task from the command line, send it to the background, watch it being relegated to the E cores.
Comment
-
-
Originally posted by Anux View PostI think the DE should be responsible to make everything that presents the user a GUI a slightly higher priority than everything else on the system, the active window even should be one step further.
Everything that gets spawned (by terminal etc) but has no user interaction should run at normal priority. Even better would be a small interface that lets you decide if something needs higher priority and runs this as desired in all future starts.
Also real time stuff like video, audio, 3D games should always have an extra priority class for RT stuff (low latency).
It's just hard to fully automate this so package maintainers would have to tag their stuff manually.
But you're not wrong. A DE should do its best to keep the priorities of rendering and event processing threads above everything else.
Comment
-
-
Originally posted by unwind-protect View PostAnother indication that simpler schedulers are competitive with Linux' complicated ones for easy to find workloads.
I once again call for a benchmark of FreeBSD versus various Linux schedulers
In a fair test Linux clearly wins against FreeBSD. However, I'm afraid Linux will be ran in powersave mode, because it's default in Ubuntu. It would be also great to use exact compiler for both operating systems in such comparison. The latest Clang was noticeably more performant than GCC.
Comment
-
-
Originally posted by commodore256 View PostOh the Rustaceans are at it again. I like the idea of memory safety on a core OS level, but as much as I like the idea, I feel if you're going to have a memory safe successor to C, do it right. I wish there was more stuff in Zig, a way better language.
Comment
-
-
Originally posted by bug77 View Postcj.wijtmans If we're lucky, Intel's heterogeneous CPUs will push more people into taking another look at scheduling.
Even though Win11 was touted to be the first OS to have proper support for those, it was still tripping on this very scenario: start whatever high-priority task from the command line, send it to the background, watch it being relegated to the E cores.
Comment
-
-
I think several people might be missing the really cool feature here. The opportunity to dynamically change schedulers per workload makes things much better for *any* environment as you can configure what your machine does and what's your priority. It's not about having one scheduler be perfect it's about the Unix philosophy of one tool per thing, now you can use what is needed when it's needed. Now to create the meta scheduler scheduler.
Comment
-
Comment