Philip WithnallJan 23

Is it possible to temporarily increase the niceness of a process (i.e. lower its scheduling priority), then later increase it again to the original value, from within the process?

Every approach I try seems to require `CAP_SYS_NICE` or a very loose `ulimit -e`, and given that I just want to make the process nicer for a bit, and then set it back to its previous niceness, this seems like too big a restriction.

What am I missing?

(I have tried setpriority(), nice() and sched_setparam())

#POSIX

Show threadAdrian VovkJan 23

@pwithnall Untested idea: I wonder if you can talk to rtkit? Usually it's used for _raising_ the scheduling priority of the process but maybe it works for lowering too?

Also, just curious, what's this for?

Show threadPhilip WithnallJan 24

@AdrianVovk From some quick testing with D-Feet, that does seem to work! Excellent, thank you.

It’s for raising the niceness of gnome-software when it doesn’t have a window open, particularly for when it’s launched as a background process on session start.

Show threadAdrian VovkJan 25

@pwithnall This should probably be a platform feature. Background apps vs foreground apps vs _focused_ foreground apps are three different categories that the OS probably should promote/demote apps between without their involvement

Also, it might be possible to reassign your systemd slice at runtime? That way gnome-software (and in future, other apps via a platform feature) can jump between background.slice and app.slice. That can come with settings like Nice, CPU affinity allocation, etc

Show threadBasiqueEvangelist

@AdrianVovk @pwithnall from what I can tell it's pretty easy to do this with org.freedesktop.impl.portal.Background, I made a prototype of that and tested it around. Problem is you hit issues like e.g. some chromium/electron apps reorganizing themselves into a app-org.chromium.Chromium scope, which causes issues.

I'll try and see if systemd slice reassigning works.

Jan 31 at 10:58amWeb
Show threadPhilip WithnallFeb 3
@BasiqueEvangelist You’re saying the background portal changes process niceness or app cgroup slice? If so, that would be great. I’ve just grepped through all the xdg-desktop-portal and xdg-desktop-portal-gnome code, though, and can’t see where it does that. The background portal seems to just kill apps which have no window and don’t have background permission. Am I looking in the wrong place?
Show threadBasiqueEvangelistFeb 3
@pwithnall No, I meant that you can ask the background portal backend for what apps are in the background/foreground and adjust based on that, in a different daemon. Sorry if I misled you :)
Show threadBasiqueEvangelistFeb 3

@pwithnall Like, I have a prototype of this (called quotamanaged for now), that asks the KDE background impl portal (though you should be able to change it to use the GNOME one) for what apps are in the foreground and background, and changes their CPUWeights to match.

This is simple enough that it would be possible to upstream to xdg-desktop-portal itself, though I have no idea if it would be accepted there.

(I can publish the source code if needed, though it's really simple)

Show threadPhilip WithnallFeb 3
@BasiqueEvangelist Sounds interesting! Plumbing that all up is a step beyond what I have time allocated for at the moment, but it’s good to know there could be something for me to switch gnome-software to use in the future! 😁