System76-Scheduler 2.0 Released With PipeWire Integration, Performance Optimizations

[phoronix]

Phoronix: System76-Scheduler 2.0 Released With PipeWire Integration, Performance Optimizations

Last year the Pop!_OS software developers at System76 introduced system76-scheduler as a Rust-written user-space daemon intended to auto-configure CFS and dynamically manage process priorities. They've added various features to improve the Linux desktop responsiveness and performance while today they rolled out system76-scheduler v2.0 as the latest iteration of this process scheduler...

https://www.phoronix.com/news/System76-Scheduler-2.0

[Quackdoc]

I wonder how well, or bad it works on arch

[mb_q]

A possible downside is that a basic on-line meeting is gonna spin-up cpu and consequently set all fans to max to support load spikes that will never happen... There are tasks that require real-time-class latencies, but they are rare on an average modern desktop.

[hax0r]

I'm curious how system76-scheduler compares to Ananicy-Cpp, I used neither, Ananicy-Cpp appears to be just renicing processes based on predefined ruleset. CachyOS uses it and ships pretty good ruleset.

system76-scheduler, in addition to renicing processes, also "Low latency CPU scheduling" activates on AC, whatever this means...I don't know, might be similar to https://github.com/igo95862/cfs-zen-tweaks bash script that tweak vanilla CFS settings to resemble those of linux-zen

What's cool about system76-scheduler is that is has DBus interface allowing foreground processes (focused windows?) to be auto prioritized, very cool, but only works if you're running pop-shell, however I found out that 'maxiberta' created a KWin script that:

interactively notifies System76 Scheduler which app has focus via D-Bus, so it is prioritized.

https://github.com/maxiberta/kwin-sy...er-integration
Very cool, definiately a good combo for ultimate KDE desktop.

[Linuxxx]

A possible downside is that a basic on-line meeting is gonna spin-up cpu and consequently set all fans to max to support load spikes that will never happen... There are tasks that require real-time-class latencies, but they are rare on an average modern desktop.

How & why should a "basic on-line meeting spin-up CPU cores and consequently set all fans to max to support load spikes that will never happen"?

Seems to me that you don't realize that all modern CPUs are putting the cores to sleep whenever possible anyway, which is also the reason why using the performance governor at all times isn't causing a significantly higher amount of power usage & fan noise.

On-topic:

While it's good to see that such options exist for those that like to micro-manage their systems, personally I prefer a low-latency configuration approach which is general enough so that my systems can handle a large amount of diverse loads without having to assign specific rules to individual tasks/processes.

To each their own, I guess...

[PAUL007]

How is this scheduler different from PDS one in terms of performance

[mmstick]

While it's good to see that such options exist for those that like to micro-manage their systems, personally I prefer a low-latency configuration approach which is general enough so that my systems can handle a large amount of diverse loads without having to assign specific rules to individual tasks/processes.

This design does not require much in the way of micromanaging. It can automatically infer an ideal profile to assign to most processes by their cgroup and/or the process that it descended from. With the cgroup information alone, you can readily distinguish between system services and processes, session services, and applications.

The pipewire integration uses libpipewire to monitor processes that are actively streaming to it, and automatically assigns them to a pipewire profile to ensure that music, videos, or conference calls can function without micro-stutters when they're in the background.

The window manager integration with pop-shell allows the service to differentiate between foreground and background applications, assigning the focused window to the foreground profile, and other unassigned processes not connected to pipewire to the background profile.

How is this scheduler different from PDS one in terms of performance

It's not the same thing. PDS is an actual scheduler in the kernel. System76 Scheduler is assigning policies and priorities so that the scheduler in the kernel can make better decisions with prioritizing the most important processes.

[Quackdoc]

The window manager integration with pop-shell allows the service to differentiate between foreground and background applications, assigning the focused window to the foreground profile, and other unassigned processes not connected to pipewire to the background profile.

can this be achieved with the toplevel-* protocols that are PRs in wayland protocols?

[mmstick]

can this be achieved with the toplevel-* protocols that are PRs in wayland protocols?

If the Wayland compositor knows the process IDs of its windows, then it can communicate that to the scheduler daemon.