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

  • fuzz
    replied
    Originally posted by lyamc View Post
    Okay Pop_OS!, you’ve finally got my attention. I’ll give you a try
    I just installed this on fedora form source. Working great!

    Leave a comment:


  • hakavlad
    replied
    Will this work with
    Code:
    kernel.sched_autogroup_enabled=1
    ?

    Leave a comment:


  • arun54321
    replied
    I'm using linux-tkg-pds with anacity-cpp. Now desktop is responsive and no stutters.

    Leave a comment:


  • dfyt
    replied
    Originally posted by ms178 View Post
    They yield at best only around half of the FPS which I get with a custom-compiled Xanmod Kernel. As you see, there is much performance left to be had already. I managed to squeeze another 10 % improvement on top of that with a lot of effort in compiling other gaming related packages with aggressive compiler flags
    While I'm a fan of Intel-Clear and Xanmod I find it to be less responsive than linux-amd or the stock arch kernel. Yes it kills on full speed cpu tasks (encodes and games) but the overall ui has microstutters compared.

    Leave a comment:


  • sn99
    replied
    Is it different from ananicy?
    Ananicy - is Another auto nice daemon, with community rules support (Use pull request please) - GitHub - Nefelim4ag/Ananicy: Ananicy - is Another auto nice daemon, with community rules support (Use pull request please)

    Leave a comment:


  • nranger
    replied
    Originally posted by arQon View Post

    No, but AFAIK none of the Linux DEs actually handle it at all, let alone competently...
    It doesn't help foreground GUI apps, but at least gnome does have an option for high priority scheduling.
    It's under 'org.gnome.mutter.experimental-features' with the value ["rt-scheduler"]. I think I had to add CAP_SYS_NICE to the gnome-shell binary to make it work as well. For me it noticeably improved mouse/touchpad responsiveness when under load. Even so, it still wasn't as effective as boosting Firefox to nice -10 or running package builds under nice 19.

    As you stated, there is a huge opportunity where Linux DEs COULD be more actively prioritizing tasks to make the experience more responsive. Heck, even Android had "Project Butter" all the way back in 2012 to reduce latency and improve touch-input responsiveness.

    Leave a comment:


  • jacob
    replied
    Originally posted by arQon View Post

    No, but AFAIK none of the Linux DEs actually handle it at all, let alone competently.

    Windows has, since the original NT days, basically automatically nice'd the focused window at about -2, thus guaranteeing that it gets preferential treatment over the windows that you're, y'know, NOT interacting with. It's significantly valuable for any desktop machine, but especially so for older machines with very few cores.

    Despite some fairly stupid and petty limitations in how Linux handles nice, that approach has been available since the dawn of time (and I expect has also been reinvented in cgroups) but was never leveraged, for whatever reason. (There are / were ancient threads about this in at least the GNOME forums / bugtracker / etc, which are probably still kicking around on the web somewhere).
    Actually ever since the advent of CFS, Linux has nice mainly for backwards compatibility but it doesn't work very well. It doesn't have to anyway since we have cgroups. The active application could just get it's CPU weight boosted, or even the others could be capped in terms of total CPU usage.

    Leave a comment:


  • arQon
    replied
    Originally posted by bachchain View Post
    Is desktop scheduling really that big of a problem that it need it's own management daemon?
    No, but AFAIK none of the Linux DEs actually handle it at all, let alone competently.

    Windows has, since the original NT days, basically automatically nice'd the focused window at about -2, thus guaranteeing that it gets preferential treatment over the windows that you're, y'know, NOT interacting with. It's significantly valuable for any desktop machine, but especially so for older machines with very few cores.

    Despite some fairly stupid and petty limitations in how Linux handles nice, that approach has been available since the dawn of time (and I expect has also been reinvented in cgroups) but was never leveraged, for whatever reason. (There are / were ancient threads about this in at least the GNOME forums / bugtracker / etc, which are probably still kicking around on the web somewhere).

    Leave a comment:


  • lyamc
    replied
    Okay Pop_OS!, you’ve finally got my attention. I’ll give you a try

    Leave a comment:


  • mirmirmir
    replied
    always makenUOTE=ms178;n1306320]

    Desktop gaming wasn't that much of a focus of the big Linux distributions up to this point in time. Or they would have put more effort into providing an optimized out-of-the box experience like Clear Linux does in terms of performance in general. Just one example, in my testing, the default Kernels of openSUSE Tumbleweed, Manjaro, Fedora and various Ubuntu-derivatives are giving far worse performance in Company of Heroes 2 (which is heavily CPU bound and which I use for ease of testing). They yield at best only around half of the FPS which I get with a custom-compiled Xanmod Kernel. As you see, there is much performance left to be had already. I managed to squeeze another 10 % improvement on top of that with a lot of effort in compiling other gaming related packages with aggressive compiler flags, but the time and risk of breakage is hardly worth that additional effort. But it would be nice to get that performance for free by default from the distros.[/QUOTE]

    You can always make your car faster by removing unecessary stuff like windshield, body, lamp, seat. But don't expect a distro will do that for you. The major one at least.

    Leave a comment:

Working...
X