Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • varikonniemi
    Senior Member
    • Jan 2012
    • 1098

    #71
    Originally posted by unwind-protect View Post
    Another 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
    even CFS beat freebsd in most cases, imagine what EEVDF can do.

    Comment

    • varikonniemi
      Senior Member
      • Jan 2012
      • 1098

      #72
      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.

      Comment

      • ssokolow
        Senior Member
        • Nov 2013
        • 5096

        #73
        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.

        Comment

        • varikonniemi
          Senior Member
          • Jan 2012
          • 1098

          #74
          Originally posted by ssokolow View Post

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

          Comment

          • sophisticles
            Senior Member
            • Dec 2015
            • 2590

            #75
            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!

            Comment

            • Anux
              Senior Member
              • Nov 2021
              • 1941

              #76
              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 ...

              Comment

              • sophisticles
                Senior Member
                • Dec 2015
                • 2590

                #77
                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.

                Comment

                • ssokolow
                  Senior Member
                  • Nov 2013
                  • 5096

                  #78
                  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.)

                  Comment

                  • Anux
                    Senior Member
                    • Nov 2021
                    • 1941

                    #79
                    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.

                    Comment

                    • cj.wijtmans
                      Senior Member
                      • Mar 2016
                      • 1404

                      #80
                      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.

                      Comment

                      Working...
                      X