Announcement

Collapse
No announcement yet.

System76-Scheduler Is A New Pop!_OS Rust Effort To Improve Desktop Responsiveness

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

  • #11
    Originally posted by ms178 View Post
    At least I don't care about about the language it is written in, but if the project is effective. There is a variety of CPU schedulers on the Kernel-level already and noticed small improvements lately while using PDS/BMQ but nothing too major. As this project comes from the user-space side, is this a potential limitation?
    It's in a different ballpark. A kernel-level scheduler has no knowledge about what processes it should be giving priority to. All it can do is offer a nice parameter that something in the userspace can configure. Processes have always had the ability to define their own nice values, but most of them avoid touching their own priority, even though ideally it might be useful if a process were to assign itself to 19 when they plan to be idle, and if compiler processes did this by default to avoid slowing down a developer's machine while the IDE is doing code completion as they type.

    This does tweak the CFS to make it low latency, but it's also assigning nice values to userspace processes based on either a defined default or input from the window manager instructing it about which process in the system the user is actively interacting with. If you're interacting with a web browser, the web browser and its descendants would get high priority; whereas the Zoom, Discord, and Steam processes in the background would get a low priority. The kernel doesn't have that info, but the window manager does.

    Comment


    • #12
      Originally posted by skeevy420 View Post

      I suppose other environments would have to be patched to support this, then.

      Who is running Kwin on top of the Pop Shell?
      Unless they have a way of getting that information through an extension or as a service, such as how gnome-shell provides window focus notifications to GNOME Shell extensions. I've heard devilspie2 offers scriptable window notification events on GTK desktops.
      Last edited by mmstick; 02 February 2022, 04:51 PM.

      Comment


      • #13
        Is desktop scheduling really that big of a problem that it need it's own management daemon?

        Comment


        • #14
          Originally posted by mmstick View Post

          It's in a different ballpark. (...).
          Getting answers directly from the developer of the project

          Comment


          • #15
            can we get systemd rewrite in rust ?

            Comment


            • #16
              Originally posted by amxfonseca View Post
              Seems an interesting idea if it makes a noticeable difference. Hopefully it can also work with different shells.


              Although it is a Rust project, and to make things worse, it does not use GPL license. This will indeed trigger some of the purists out here.
              Well, at least the idea of giving the desktop environment a higher priority seems like a du-uh moment.
              Originally posted by ms178 View Post
              At least I don't care about about the language it is written in, but if the project is effective. There is a variety of CPU schedulers on the Kernel-level already and noticed small improvements lately while using PDS/BMQ but nothing too major. As this project comes from the user-space side, is this a potential limitation?
              Schedulers always yield "nothing too major". They're a balancing game and as such, you can't tailor them too specific to some workloads, because you'll hurt others. The idea here seems to be make the configuration of the scheduler dynamic instead. I can see that working, if executed right.

              Comment


              • #17
                system76-schedulerD

                Comment


                • #18
                  I hope this is implemented well

                  Comment


                  • #19
                    Sounds like a behavior that should have been the default on all non-server distributions from the beginning of time. Why has it not been the case?

                    Comment


                    • #20
                      Originally posted by bachchain View Post
                      Is desktop scheduling really that big of a problem that it need it's own management daemon?
                      It is actually. Optimising for perceived responsiveness and balancing that against battery lifetime and cooling requirements is a difficult problem

                      Comment

                      Working...
                      X