Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

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".

Pictured - Pop!_OS 21.10.

Sounds like Pop!_OS is doing increasingly awesome work to make Linux a great desktop operating system for gamers and creatives.

Article taken from GamingOnLinux.com.
16 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
27 comments
Page: «2/3»
  Go to:

edo Feb 3, 2022
So basically feral game mode. But hopefully more maintained. I hope it will arrive to arch repos soon
elmapul Feb 3, 2022
i'm not into distro hopping anymore, can someone benchmark this and see if it make a huge difference?
i dont have free space or HDD's avaliable to test myself.

anyway, this tech dont seem impresssive, i'm a bit tired of seing huge improvments in the proprietary software world, and gimmicks on the free one.
dont get me wrong, blender and godot are amazing, but i'm still not convinced that an new desktop enviroment is nescessary and will help linux grow instead of just fragment.
sometimes it seems like we are just reinventing the whell and "stealing" money from other distros instead of developing some real tech
compare lumen /nanite from unreal engine to this, what have the bigger potential to be an game changer?
some "rocket science" algorithms to allow an "unlimited" ammount of polygons to be rendered on screen in real time, with another "cutting edge" tech to make lights ingame feel almost as good as raytracing without the processing cost of raytracing in scenes with that ammount of polygons...

meanwhile we get hyped at stuff like "automatically seting your cpu to performance mode when you gonna game" or "automatically seting priorities straight for processes"
hell, even microsoft is doing some nice inovative stuff, directX 12 came before vulkan was a thing.

i know system 76 is not as big as epic or microsoft, the question is, maybe the path for linux to go foward is, using the money that can only be gained by selling proprietary software and using it to fund open source, like what valve is doing funding wine/proton, vulkan, mesa, futex, etc.

i know this leave an sour taste on our mouth, the question is "the goals justify the means"
and an philosofical discussion i would like to propose:
if we give up having many stores to rely only on steam and stuff that work well with lutris/heroic, because those work well with linux , we are giving up part of or "freedom"
if we give up on the ability to change the wallpaper as canonical was proposing with ubuntuphone to try to convince oems to adopt the system (aka seling the consumers wallpaper as an place to put brand adivertise )
we give up having many tools, like tools to make mods (eg: custom maps for an specific game)
give up using floss drivers because the proprietarys are better.

and so on... at some point we end up with less freedom than on windows...

sigh...
sorry for the confusing comment, i cant formulate phrases in english right now.
ElectricPrism Feb 3, 2022
I like their Launcher. I thought it was Slingshot / Panther_Launcher by Rastersoft for a second there.
Purple Library Guy Feb 4, 2022
Quoting: elmapulhell, even microsoft is doing some nice inovative stuff, directX 12 came before vulkan was a thing.
I don't remember it being quite like that. Didn't they kind of get developed/specified around the same time? DX12 might have been officially released before Vulkan was quite finalized, but it was all happening about the same time and basically drawing on the same ideas, which were being developed mostly in public.
elmapul Feb 4, 2022
Quoting: Purple Library Guy
Quoting: elmapulhell, even microsoft is doing some nice inovative stuff, directX 12 came before vulkan was a thing.
I don't remember it being quite like that. Didn't they kind of get developed/specified around the same time? DX12 might have been officially released before Vulkan was quite finalized, but it was all happening about the same time and basically drawing on the same ideas, which were being developed mostly in public.

the ideas are the same, because the hardware is the same, and its about being low level, not about building a lot of libraries on top of the hardware, so i think its natural to come to the same conclusions, but i dont know much about low level programing, nor about the development being public.
i dont know if the khronos group is something akin to w3c with public proposals that get adopted by the browser vendors in different speeds or what, what i do know is that the gaming market try to squeze every little bit of performance from the hardware and microsoft was the first to offer an solution in that regard, wich gave then a big advantage, or maybe their product was adopted by more companies due to the windows marketshare.
maybe mobile games use vulkan and it can be argueed that more developers chose vulkan than dx12, but while mobile gamers are an bigger and more profitable market, they suck in general (almost all are pay to win gacha games) so i dont count then really as gaming...
Cybolic Feb 4, 2022
Quoting: CybolicThis 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
DebianUser Feb 4, 2022
Quoting: Cybolic
Quoting: CybolicThis 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 ?
Cybolic Feb 4, 2022
Quoting: DebianUser
Quoting: Cybolic
Quoting: CybolicThis 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.
mmstick Feb 4, 2022
What ananicy does is only a fraction of what system76-scheduler is doing.
Quoting: Cybolic
Quoting: CybolicThis 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}
Cybolic Feb 4, 2022
Quoting: mmstickWhat ananicy does is only a fraction of what system76-scheduler is doing.
Quoting: Cybolic
Quoting: CybolicThis 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}

That would certainly be easier, yes :)
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.