Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quackdoc
    replied
    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

    Leave a comment:


  • cj.wijtmans
    replied
    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.
    pretty sure -1 to -19 is considered foreground and 1 to 19 is considered background task.

    Leave a comment:


  • Anux
    replied
    Originally posted by sophisticles View Post
    I suggest you read this:
    That doesn't change the fact that without a scheduler there is no multi tasking.
    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
    While the idea sounds nice, it's not practical. Look at how many different schedulers (performing different under diff workloads) there are for Linux alone (not to mention other OSes) and how often they get changed/optimized. A hardware implementation would be too inflexible.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by sophisticles View Post
    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,

    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.
    iAPX The first time Intel tried to kill x86 and Intel's biggest blunder: Itanium ...sure, let's go for a hat trick.

    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:


  • sophisticles
    replied
    Originally posted by Anux View Post
    Have fun with your MSDOS and one program at a time ...
    I suggest you read this:





    On real hardware, we can run only a single task at once, so we have to introduce the concept of "virtual runtime."
    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,

    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:


  • Anux
    replied
    Originally posted by sophisticles View Post
    I think that the best approach is to not have a scheduler at all.
    Have fun with your MSDOS and one program at a time ...

    Leave a comment:


  • sophisticles
    replied
    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:


  • varikonniemi
    replied
    Originally posted by ssokolow View Post

    It sounds like you think
    i was not thinking after a few too many glasses of wine. Sorry.

    Leave a comment:


  • ssokolow
    replied
    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.
    It sounds like you think I'm against more Rust in the kernel. I'm not.

    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:


  • varikonniemi
    replied
    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.
    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.
    Last edited by varikonniemi; 21 January 2024, 11:57 AM.

    Leave a comment:

Working...
X