Rust-Written Linux Scheduler Showing Promising Results For Gaming Performance

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • szymon_g
    Senior Member
    • Sep 2008
    • 408

    #51
    Originally posted by Britoid View Post
    does anything similar the moment and probably explains why Windows still feels more responsive.
    that's a highly debatable phrase. on my machine (octacore zen3 cpu, 24 ddr5 ram, nvme3 drive) ubuntu with gnome/kde eats w11 for breakfest when it comes to responsiveness during normal usage (nothing too heavy)

    Comment

    • cj.wijtmans
      Senior Member
      • Mar 2016
      • 1404

      #52
      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.
      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.
      Last edited by cj.wijtmans; 17 January 2024, 10:03 AM.

      Comment

      • Anux
        Senior Member
        • Nov 2021
        • 1941

        #53
        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.
        I 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.

        Comment

        • bug77
          Senior Member
          • Dec 2009
          • 6513

          #54
          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

          • bug77
            Senior Member
            • Dec 2009
            • 6513

            #55
            Originally posted by Anux View Post
            I 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.
            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. 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?).
            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

            • Volta
              Senior Member
              • Apr 2019
              • 2273

              #56
              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
              EEVDF is very intuitive and natural. It's matter of process prioritization. Scheduler isn't much aware what is more important for you, unless you tell it.

              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

              • Volta
                Senior Member
                • Apr 2019
                • 2273

                #57
                Originally posted by szymon_g View Post

                that's a highly debatable phrase. on my machine (octacore zen3 cpu, 24 ddr5 ram, nvme3 drive) ubuntu with gnome/kde eats w11 for breakfest when it comes to responsiveness during normal usage (nothing too heavy)
                The same experience here.

                Comment

                • Quackdoc
                  Senior Member
                  • Oct 2020
                  • 5056

                  #58
                  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.
                  Im personally not a fan with zig, in a lot of ways to me it just feels like rust with the optional steps mandatory

                  Comment

                  • F.Ultra
                    Senior Member
                    • Feb 2010
                    • 2040

                    #59
                    Originally posted by bug77 View Post
                    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.
                    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.

                    Comment

                    • JosiahBradley
                      Junior Member
                      • Aug 2006
                      • 39

                      #60
                      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

                      Working...
                      X