Nice all threads of multithreaded programs
AcceptedPublic

Authored by jpalecek on Mon, May 11, 1:45 AM.

Details

Summary

Setting process priorities by ksysguard has the flaw that it only
sets priority of a single thread of a multithreaded program. For
example, if I want to put handbrake encoding to the background, it
usually fails as other threads from the same process continue to hog
the CPU. This patch changes the behavior by attempting to change the
priority of all threads (on Linux).

There is a caveat: when the threads' priorities were previously
different, it may mean you change the priority against the logic of
the application. For example some background threads of an
application might end up having the same priority as the
foreground. As a corollary, the call may mean lowering priority of
some threads, but raising it for others and thus fail due to
insufficient capabilities. Still, I think this behavior is actually
the only one usable, until we have individual threads in
ksysguard. Even then, I doubt people will look at the individual
threads when renicing. Till then, the ability to renice a task is a
need which ksysguard should fulfill, but unfortunately doesn't.

Note: this only changes the behavir for remote computers. Local use
needs a similar fix in libksysguard.

Test Plan
Run a multithreaded process which uses the CPU (like video coding)
Set its priority to low
Check with ps -p $pid -L o pid,lwp,pri,comm

Diff Detail

Repository
R106 KSysguard
Branch
Plasma/5.18
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 26678
Build 26696: arc lint + arc unit
jpalecek created this revision.Mon, May 11, 1:45 AM
Restricted Application added a project: Plasma. ยท View Herald TranscriptMon, May 11, 1:45 AM
jpalecek requested review of this revision.Mon, May 11, 1:45 AM
davidedmundson accepted this revision.Tue, May 12, 3:10 PM

Still, I think this behavior is actually the only one usable,

Indeed. A user shouldn't be expected to know what each thread is doing inside an app, there isn't enough metadata to do anything useful there anyway. Especially with use of threadpools.

FWIW, I've been taking this logic further in the other direction from looking at threads. From 5.19 spawned apps will each have their own cgroup. The intention being to get to a point (5.20 or so) where we can do management on an entire cgroup (and therefore app with multi processes and threads) all at once. The management is way nicer, the UX is nicer, and we won't have this sort of problem.


Note: this only changes the behavir for remote computers. Local use needs a similar fix in libksysguard.

Yeah, that's the more useful one.

ksysguardd/Linux/ProcessList.c
657

heh, our use of PID is already racey

This revision is now accepted and ready to land.Tue, May 12, 3:10 PM