Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Insultikarp
    Junior Member
    • Jan 2024
    • 4

    #61
    Originally posted by ZarathustraDK View Post
    *Silently wondering if there's an optimal scheduler for VR*

    For real though, there's a bunch of unique timing-problems when it comes to VR and its frametimes and whatnot that ends up triggering reprojection or messing with reprojection. Could be interesting to see what a dedicated VR-scheduler could do. And yes, I'm talking out my ass here since I don't have the slightest idea about the technical details, but just to underline the woeful state of VR on linux: we have to manually (or set up the gpu to automatically) change the p-state with corectrl, the scheduler is probably in a comparative state, I assume.
    System76 specifically called out VR as one of their test cases when building the system76-scheduler.

    Comment

    • ssokolow
      Senior Member
      • Nov 2013
      • 5096

      #62
      Originally posted by commodore256 View Post
      Oh 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.
      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.

      Comment

      • cj.wijtmans
        Senior Member
        • Mar 2016
        • 1404

        #63
        Originally posted by F.Ultra View Post

        This is one area where macOS is a bit better since you there can inform the system when you create a thread if it would benefit from a performance core or if it is for more background things and thus can better run on a efficiency core.
        you can do the same on linux though? You can either set niceness to 19 to 1 or -1 to -19 or you can set sched policy to SCHED_IDLE or SCHED_BATCH.
        GUI threads should probably be set to FIFO or RR? i wonder which one would be better.

        https://man7.org/linux/man-pages/man...heduler.2.html
        Last edited by cj.wijtmans; 17 January 2024, 05:16 PM.

        Comment

        • bug77
          Senior Member
          • Dec 2009
          • 6513

          #64
          Originally posted by F.Ultra View Post

          This is one area where macOS is a bit better since you there can inform the system when you create a thread if it would benefit from a performance core or if it is for more background things and thus can better run on a efficiency core.
          Are you sure macOS does that? On which heterogeneous CPU does it run?

          Comment

          • Anux
            Senior Member
            • Nov 2021
            • 1941

            #65
            Originally posted by bug77 View Post
            It's easy to describe that in words. The problems start arising when you have to deal with tasks that they all need higher priority than everything else.
            I don't quite get that, some words seem wrong?

            Essentially you only need 5 different priorities:
            • lowest background: everything that should never interfere with anything else (like updates)
            • normal
            • user: everything with a GUI that has to interact with the user
            • active: the active window and everything that the user want's to prioritize.
            • RT: audio, video, games

            Scheduling is ultimately at kernel's discretion, a DE can only set hints. And a DE does not start all the processes in an OS (Ctrl+Alt+F3 anyone?).
            Of course the DE gives only hints like you would if you manually use nice or policies like SCHED_BATCH. Any non DE component must either have it's own managing or run at the standard priority.

            A DE should do its best to keep the priorities of rendering and event processing threads above everything else.
            A smooth experience for the user is what every DE should want. No buttons that don't give instant feedback about being pressed or programs not responding. Video and even more so audio stutter shouldn't be a thing as long as the hardware can handle it at idle it also should run the same under full load.

            Comment

            • geearf
              Senior Member
              • Dec 2011
              • 2150

              #66
              Originally posted by ffs_ View Post

              I'd test at least more than one scenario:

              0. Minimal background tasks
              1. Many light load background tasks
              2. Running heavy load task in the background
              3. 1+2 combined
              It's possible that the scheduler is worse in some other scenarios so it's been shown so far for the one it's good at.

              Comment

              • F.Ultra
                Senior Member
                • Feb 2010
                • 2040

                #67
                Originally posted by cj.wijtmans View Post

                you can do the same on linux though? You can either set niceness to 19 to 1 or -1 to -19 or you can set sched policy to SCHED_IDLE or SCHED_BATCH.
                GUI threads should probably be set to FIFO or RR? i wonder which one would be better.

                https://man7.org/linux/man-pages/man...heduler.2.html
                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.

                What macOS have is a pthread function (pthread_set_qos_class_self_np​) to set the QoS Class for a thread where the QoS Class can be "User-interactive", "User-initiated", "Utility" and "Background". And this is something that I hope that we could copy to Linux if the use of P-cores and E-cores becomes prevalent.

                Last edited by F.Ultra; 18 January 2024, 10:07 AM.

                Comment

                • F.Ultra
                  Senior Member
                  • Feb 2010
                  • 2040

                  #68
                  Originally posted by bug77 View Post

                  Are you sure macOS does that? On which heterogeneous CPU does it run?
                  Yes they have implemented a new pthread function, pthread_set_qos_class_self_np​, for this. Their M1 chip have 4 P-cores and 4 E-cores, the M2 have a wider variety (from 4+4 to 16+8) and M3 further have various configurations in 4+4, 6+6 and 12+4 (with a few variations).

                  Comment

                  • MartinN
                    Official Linux/Wayland/systemd fanboy
                    • Nov 2010
                    • 531

                    #69
                    Originally posted by phoronix View Post
                    Phoronix: Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance

                    A Canonical engineer has been experimenting with implementing a Linux scheduler within the Rust programming language. His early results are interesting and hopeful around the potential of a Rust-based scheduler that works via sched_ext for implementing a scheduler using eBPF that can be loaded during run-time...

                    https://www.phoronix.com/news/Rust-L...ler-Experiment
                    Won't trust this until Michael benchmarks it

                    Comment

                    • varikonniemi
                      Senior Member
                      • Jan 2012
                      • 1098

                      #70
                      Originally posted by V1tol View Post
                      I am not sure what happens with that scheduler but the effect looks to me the same as applying schedtool and ionice. On my 5950X doing nice by only 1 makes a huge difference in responsiveness. Confirmed multiple times by compiling kernel or mesa and doing casual internet surfing at the same time - impact becomes almost unnoticeable. Didn't try to game ofc since all my games are very demanding.
                      You have 1 gen newer processor than i do, and still i can barely notice a kernel compilation going on in the background. What is the issue? Are you on a kernel with EEVDF?

                      I did not try using nice, but specifying -j n-1 likewise makes the compilation absolutely unnoticeable for normal web browsing.

                      you mentioned ionice, do you have a slow storage media that becomes bottleneck? (but why would this affect internet browsing which is not hitting the disk?)
                      Last edited by varikonniemi; 21 January 2024, 08:27 AM.

                      Comment

                      Working...
                      X