Placing the entire Xserver and GUI inside a cgroup/slice?

k4my4b · 2020-11-09 00:20:22

With the intent to guarantee a minimum amount of CPU cycles to keep the desktop environment smooth and snappy,

Questions:

Is it doable?
Would this be a good idea?
How would you go about doing this?

Side Question:

How does Linux go about GPU resource scheduling or is that done by the driver?

kokoko3k · 2020-11-09 07:19:43

What is the theory behind it?
I mean... how could limit resources to the whole session improve his performance?
cgroup limits resources, so you'd have to put everything else in a limited cgroup, but is overkill.
Do you really have background tasks started before the Xorg session that steals so many system resources? Deal with them one by one, find lighter alternatives, limit them.

GPU scheduling depends on the type of workload and the driver itself, be more specific.

k4my4b · 2020-11-09 16:31:59

Q:

kokoko3k wrote:

What is the theory behind it?

A:

k4my4b wrote:

...to guarantee a minimum amount of CPU cycles to keep the desktop environment smooth and snappy,

Q:

kokoko3k wrote:

I mean... how could limit resources to the whole session improve his performance?
cgroup limits resources, so you'd have to put everything else in a limited cgroup, but is overkill.

A:

Cgroups can be guaranteed a minimum number of "CPU shares" when a system is busy. [Cgroups(7) - Linux Manual Page. Accessed November 09, 2020. https://man7.org/linux/man-pages/man7/cgroups.7.html].

Q:

kokoko3k wrote:

Do you really have background tasks started before the Xorg session that steals so many system resources?
Deal with them one by one, find lighter alternatives, limit them.

A:

Encoding, decoding, compiling, rendering etc...
Limiting everything else along with everything that doesn't exist on the system yet is far less plausible than isolating the graphical-target perhaps and guaranteeing a minimum amount of system resources based on your needs to keep the GUI responsive.
Some may be happy with 20% of CPU shares some may want 90%, some still use 60Hz panels some are 'trying to' use 144hz, 240hz ...
Microsoft already does this with their DE and we can all agree that it's (almost always) silky smooth, we should perhaps make an effort to do the same?
There is some work being done on kwin by "tildearrow": https://github.com/tildearrow/kwin-lowlatency

kokoko3k · 2020-11-09 22:23:51

So, if i understood well, you run a lot of heavy tasks outside of the graphical session and don't want them to bug your desktop snappiness.
If this is correct, you just can setup an alias like this:
alias benice="renice -n 19 -p $$ && ionice -c3 -p $$ && schedtool -B $$"
run it once in the shell outside your graphical session and any subsequent command in that shell will run with a low priority.
...you can run that in the graphical session too, of course.

This way is even "smoother" than using cgroups and fixed time slicing,
hogging jobs will only run when the other non-deprioritized tasks aren't busy.
Also, take into account that cpu limiting via cgroups, and in reverse the minimum cpu time allowed, is not so granular for you to not notice it.

PS: what is microsoft doing exactly, since afaik there is no concept of graphical target and how does the removal of a timer in kwin code relates to cgroups or priorities?

Last edited by kokoko3k (2020-11-09 22:28:26)

k4my4b · 2020-11-09 22:57:37

kokoko3k wrote:

So, if i understood well, you run a lot of heavy tasks outside of the graphical session and don't want them to bug your desktop snappiness.
If this is correct, you just can setup an alias like this:
alias benice="renice -n 19 -p $$ && ionice -c3 -p $$ && schedtool -B $$"
run it once in the shell outside your graphical session and any subsequent command in that shell will run with a low priority.
...you can run that in the graphical session too, of course.

I'm already running ananicy (https://github.com/Nefelim4ag/Ananicy).

kokoko3k wrote:

This way is even "smoother" than using cgroups and fixed time slicing,
hogging jobs will only run when the other non-deprioritized tasks aren't busy.
Also, take into account that cpu limiting via cgroups, and in reverse the minimum cpu time allowed, is not so granular for you to not notice it.

Now that's the kinda thing I would like to know, the nitty-gritty details and pitfalls. So cgroups don't directly tie-in with the kernel's scheduler?
I don't know how the kernel scheduler is implemented but at least in networking, this is easily achieved by the likes of HFSC, HTB and cake.

kokoko3k wrote:

PS: what is microsoft doing exactly, since afaik there is no concept of graphical target

I mean the GUI/DE, Long ago while I was researching I found somewhere in their docs that they guarantee a minimum of 20% for the GUI, that may have changed by now.

kokoko3k wrote:

and how does the removal of a timer in kwin code relates to cgroups or priorities?

That was in regards to a smooth/stutter-free desktop (not cgroups) which is what this whole topic is about.

seth · 2020-11-10 07:28:16

Off topic:
The repaint timer in kwin exists because Qt4 couldn't do threaded GL - just doing one cycle of other stuff and then blocking in the vsync for 10+ ms will not improve the situation at all (because a WM does more stuff than just rendering an image)
The solution to the problem is to implement multithreading (which should have been available at some point in Qt5)

Arch Linux

#1 2020-11-09 00:20:22

Placing the entire Xserver and GUI inside a cgroup/slice?

#2 2020-11-09 07:19:43

Re: Placing the entire Xserver and GUI inside a cgroup/slice?

#3 2020-11-09 16:31:59

Re: Placing the entire Xserver and GUI inside a cgroup/slice?

#4 2020-11-09 22:23:51

Re: Placing the entire Xserver and GUI inside a cgroup/slice?

#5 2020-11-09 22:57:37

Re: Placing the entire Xserver and GUI inside a cgroup/slice?

#6 2020-11-10 07:28:16

Re: Placing the entire Xserver and GUI inside a cgroup/slice?

Board footer