System76 Scheduler 1.2 Released - Now Has Defaults For SteamVR, Flatpak Process Support

[phoronix]

Phoronix: System76 Scheduler 1.2 Released - Now Has Defaults For SteamVR, Flatpak Process Support

System76-Scheduler as the Linux PC vendor's effort to provide a Rust-written daemon to enhance Linux desktop responsiveness and shipping as part of their Pop!_OS distribution is out with a new feature release...

https://www.phoronix.com/scan.php?page=news_item&px=System76-Scheduler-1.2

[mirmirmir]

Can anyone confirm the scheduler is actually improve responsiveness?

[haydn-j]

Can anyone confirm the scheduler is actually improve responsiveness?

When I'm doing large compilation jobs on all threads my system is definitely more responsive with the scheduler. Otherwise? I don't know, my generally I don't experience problems with snappiness.

[Quackdoc]

Pop seems to be the best company pushing linux desktops for the home PC, still cannot wait for their home grown shell. as for the scheduler I've heard mixed things. but I haven't tested it myself

[jorgepl]

Can anyone confirm the scheduler is actually improve responsiveness?

I've read anecdotal evidence of it improving significantly the FPSes.

[aorth]

Prior to this version it only set priorities during its own startup, meaning things like system daemons and your graphical session were probably tuned, but any newly spawned processes were not. So your CPU-intensive ffmpeg, clang, gcc, aomenc, svt-av1, rust, etc processes would not be tuned. Seems like a pretty huge loop hole!

Anyways, I tested the new version on Arch Linux and the execsnoop process monitoring causes system76-scheduler to peg the CPU at 200%. So that's not great... anyone else confirm? I will file a GitHub issue.

[-MacNuke-]

When I'm doing large compilation jobs on all threads my system is definitely more responsive with the scheduler.

Personally I just launch my compile jobs with chrt -i 0 <job>. That set's them to very low idle scheduling and I don't even notice that anything is running in the background.

[mmstick]

Before this update, it was only applying priorities once every 60 seconds. If a system has execsnoop-bpfcc installed, it will apply them in realtime.

I can't confirm that execsnoop is causing 200% CPU usage on Pop!_OS, so it may be an Arch-specific issue. All it's doing is reading the output of that program line by line, and sending the data from each line to the daemon thread through a channel. If no processes are created by the kernel, it's completely idle.

[Vistaus]

Can anyone confirm the scheduler is actually improve responsiveness?

It does, at least on openSUSE Tumbleweed. I use the scheduler with this KWin script: https://www.pling.com/p/1789957
It improves responsiveness in heavier day-to-day stuff like web browsing, but also in games.

[aorth]

Before this update, it was only applying priorities once every 60 seconds. If a system has execsnoop-bpfcc installed, it will apply them in realtime.

I can't confirm that execsnoop is causing 200% CPU usage on Pop!_OS, so it may be an Arch-specific issue. All it's doing is reading the output of that program line by line, and sending the data from each line to the daemon thread through a channel. If no processes are created by the kernel, it's completely idle.

Thanks for the correction about the 60 seconds. I was wondering about that.

Regarding the 200% CPU, it seems that the Arch package needed some work. We just added bcc-tools and python-bcc to the depends, and when running execsnoop interactively I realized it needs the kernel headers in order to compile the BPF module. Once I installed those everything was working well. Cheers!