Finally got around to trying this for myself I found that scx_rustland did extremely poorly when I was playing some games, however the new scx_lavd scheduler (in the same repo, also rust) did phenomenal, I was able to play my game while running aur updates (ffmpeg some rust stuff) in the background perfectly fine and didnt even notice when it was completed. without it I was playing at about 20fps for most of it, with it I was holding a solid 55+ (what I normally run)
IMO it's certainly worth playing around with I think it will be a wonderful addition
Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance
Collapse
X
-
Originally posted by F.Ultra View Post
The issue though is that there is no definition here on what nice value counts as background and which ones that counts as foreground so AFAIK the scheduler does not takes this into account when determining if to put threads on a E-core or P-core. And SCHED_IDLE+SCHED_BATCH simply tells the system that you only want to run on whatever cpu time is left after everyone else have run so that is not really something to base E vs P on.
Leave a comment:
-
-
Originally posted by sophisticles View PostI suggest you read this:
If AMD, and intel, really wanted to innovate instead of looking to add more cores with every release they would look to create add a hardware thread scheduler right on the CPU, so that the kernel wouldn't have to decide how to assign threads, the CPU would do that
Leave a comment:
-
-
Originally posted by sophisticles View PostIf AMD, and intel, really wanted to innovate instead of looking to add more cores with every release they would look to create add a hardware thread scheduler right on the CPU, so that the kernel wouldn't have to decide how to assign threads, the CPU would do that,
They don't even have to spend a lot to redesign the CPU, they could add a small dedicated chip on the motherboard with microcode who;s only function is to assign threads.
TL;DR: The common thread in those cases was trying to add CPU-level smarts and complexity reminiscent of what​ you're proposing and, right now, what AMD and Intel are struggling when benchmarked against Apple Silicon is the legacy baggage of not being able to ditch the complex instruction x86 ISA necessitates being slapped on top of an internally RISC chip for a long time now. (Specifically, the fact that instructions can't be decoded in parallel SIMD style because x86 has variable-length opcodes.)
Leave a comment:
-
-
Originally posted by Anux View PostHave fun with your MSDOS and one program at a time ...
On real hardware, we can run only a single task at once, so we have to introduce the concept of "virtual runtime."
They don't even have to spend a lot to redesign the CPU, they could add a small dedicated chip on the motherboard with microcode who;s only function is to assign threads.
Leave a comment:
-
-
I think that the best approach is to not have a scheduler at all.
And of course stop using C or Rust and rewrite the kernel, drivers, DE, everything in Go.
There, i said it because it needed to be said!
Leave a comment:
-
-
Originally posted by ssokolow View Post
It sounds like you think
Leave a comment:
-
-
Originally posted by varikonniemi View Post
Don't you understand? All in any case ever the processor sees is binary code. Still Rust has it's properties.
The thing is, the bytecode you feed the processor must be correct, or you have bugs. Rust eliminates many of these bugs. And due to the coding model it's easier to write high level code in Rust as you are working at a higher level than C
Similarly, the program you write for ebpf must be written by someone. You can do it manually (ebpf code) in a difficult way (c compiled to ebpf) or properly (rust compiled to ebpf)
granted, this is an area where rust shows least amount of benefit because the target is so restricted C cannot really shoot itself in the foot. If your c coded program compiles and loads in ebpf it either works or does not, no undefined behavior like c is famous for.
The comment you replied to was in response to one that gives me strong "I think this is Rust replacing C in a non-eBPF context and I don't agree" vibes.
Leave a comment:
-
-
Originally posted by ssokolow View Post
It's an eBPF thing. What it's written in doesn't matter any more than what "compile-to-JavaScript" things like Google Clojure are written in because all the kernel ever sees is eBPF bytecode.
The thing is, the bytecode you feed the processor must be correct, or you have bugs. Rust eliminates many of these bugs. And due to the coding model it's easier to write high level code in Rust as you are working at a higher level than C
Similarly, the program you write for ebpf must be written by someone. You can do it manually (ebpf code) in a difficult way (c compiled to ebpf) or properly (rust compiled to ebpf)
granted, this is an area where rust shows least amount of benefit because the target is so restricted C cannot really shoot itself in the foot. If your c coded program compiles and loads in ebpf it either works or does not, no undefined behavior like c is famous for.Last edited by varikonniemi; 21 January 2024, 11:57 AM.
Leave a comment:
-
Leave a comment: