System76 have done something very interesting with Pop!_OS lately, a change that should give you better performance in games and get a more responsive desktop overall on Linux.
It comes in the form of their new System76 Scheduler, which they describe as:
Scheduling service which optimizes Linux's CPU scheduler and automatically assigns process priorities for improved desktop responsiveness. Low latency CPU scheduling will be activated automatically when on AC, and the default scheduling latencies set on battery. Processes are regularly sweeped and assigned process priorities based on configuration files. When combined with pop-shell, foreground processes and their sub-processes will be given higher process priority.
These changes result in a noticeable improvement in the experienced smoothness and performance of applications and games. The improved responsiveness of applications is most noticeable on older systems with budget hardware, whereas games will benefit from higher framerates and reduced jitter. This is because background applications and services will be given a smaller portion of leftover CPU budget after the active process has had the most time on the CPU.
Announcing the update that's rolled out on Twitter, System76 engineer Michael Murphy mentioned "There's a Pop!_OS update for pop-shell and system76-scheduler being released that will give CPU priority to the focused window and its sub-processes. Which means improved performance in games, and increased responsiveness in applications".
Our friends at Linux4Everyone asked a question in regards to gaming and how it actually improved it, to which Murphy replied: "QA team had the smoothest VR gaming experience with this, and it gave a boost to framerates. Just a natural side effect of having some finely tuned process priorities that give the focused window (such as a game) a higher priority than background applications and services".
Sounds like Pop!_OS is doing increasingly awesome work to make Linux a great desktop operating system for gamers and creatives.
This sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh
Thanks, seems interesting.
I see it uses bspc command, does it require bspwm ? or it will work under mutter with bscp command installed ?
It very much depends on bspwm. If there's another tool that continuously prints out the WID when the focused window changes, it could be adapted, but I don't know of any.
Maybe "xprop -spy -root _NET_ACTIVE_WINDOW" ?
This sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh
Thanks, seems interesting.
I see it uses bspc command, does it require bspwm ? or it will work under mutter with bscp command installed ?
It very much depends on bspwm. If there's another tool that continuously prints out the WID when the focused window changes, it could be adapted, but I don't know of any.
Maybe "xprop -spy -root _NET_ACTIVE_WINDOW" ?
Doesn't have correct knowledge about the PID of the active window. Half of your applications will either have no `_NET_WM_PID` or the `_NET_WM_PID` will be a bogus value like `2`.
What ananicy does is only a fraction of what system76-scheduler is doing.I've updated it to better handle children of PPID and PID. I'm not aiming to handle the entire system with this, just the basic userspace processes to the extent that bash scripting allows without too much slow code. As for general background processes, that's what the limits.conf edit is for.This sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh
Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do
dbus-send --system --dest=com.system76.Scheduler \
/com/system76/Scheduler \
com.system76.Scheduler.SetForegroundProcess \
uint32:${PID}
Last edited by Cybolic on 4 February 2022 at 5:58 pm UTC
....also don't worry, there's been plenty of desktop innovation that Microsoft never could match. Like virtual desktops. So much so that projects such as LiteStep were created to bring desktop flexibility to Windows.
Never is not true anymore for virtual desktops, they have been available for Windows for a while without any extensions. I haven't just found real use for them with my work computer as far as I know there's no way to save the layouts. There's keyboard shortcuts (has been since Windows 7) to first ten applications, so mostly virtual desktops are not needed. I just would need direct access to more applications, ten is not enough.
Flexibility might still be something that Microsoft doesn't want to implement fully. Linux is much better suited for experimentation, but if some experiment gets too popular, nothing is stopping Microsoft from implementing it. It just might take roughly decade like with virtual desktops.
One thing is that I use an eGPU and it was a pain to get working; for whatever reason there's no implementation in Pop_OS for eGPU, you can't use their 'switchable graphics' interface, so I had to dig into the X11 files.
What ananicy does is only a fraction of what system76-scheduler is doing.I added support for using the System76 Scheduler in my little script now. Honestly, I don't see any difference in how it handles process groups in my limited testing, but it is a bit faster at changing the niceness levels.This sounds like something that could also be implemented with bspwm, so I'll be sure to keep an eye on what tweaks they're doing.Here's a quick version for anyone interested. Thanks to mmstick for correcting me on the logic.
bspwm-scheduler.sh
Doesn't appear to be applying the background process priority to all background processes, or matching all descendants of a PPID and their descendants, descendants. It'd be easier to simply do
dbus-send --system --dest=com.system76.Scheduler \
/com/system76/Scheduler \
com.system76.Scheduler.SetForegroundProcess \
uint32:${PID}
Best of both worlds now :)
See more from me