Slow X when using Chrome/Chromium/Vivaldi: take 2

0BADC0DE · 2021-11-11 14:56:03

In another thread I tried to tackle a weird issue: X-Window-bound software gets very slow and unresponsive when I use stuff like MS Teams or Google Meet. All other processes were running unhindered.
I ended up with fully hardware-accelerated browsers (Chrome, Chromium and Vivaldi) refusing to use hardware accelerated video decoding.
But this is not the real problem, despite being quite weird.

The real problem is, for example, opening a new Konsole instance requires seconds when in Teams or Meet and runs instantaneously otherwise.
When in Teams or in Meet, total CPU usage is < 10% with a loadavg < 2 (I have a CPU w/ 4 cores and 2 threads per core and 12MiB L3 cache).
Any graphical I/O (but the mouse pointer) become unresponsive and slow, while any non-graphical I/O is fast (like sound, network I/O and 80x25 console activity)
When not in those web apps, total CPU usage is < 5% and loadavg < 1.

I would say the software-based video decoding is not the problem, as my system isn't getting any close to 100% CPU usage or loadvg >= 8.
I think the culprit is some bottleneck (or race condition) happening in X during software-based video decoding (I never got hw accelerated decoding)..
But I have no clue on how to verify this hypothesis nor whether it can be fixed.

Any hint?

My /var/log/Xorg.0.log is here.

seth · 2021-11-11 21:45:37

Is trhe entire thing still strictly tied to the KWin compositor?
Do you get the same effects w/o compositing or w/ picom instead of the kwin compositor?

0BADC0DE · 2021-11-12 07:53:29

seth wrote:

Is trhe entire thing still strictly tied to the KWin compositor?
Do you get the same effects w/o compositing or w/ picom instead of the kwin compositor?

As soon as I will get my first Teams call I will check by disabling the compositor.
To replace kwin with picom I am going to use this guide and will check with the next one.

seth · 2021-11-12 08:05:38

You can toggle the kwin compositor w/ Shift+Alt+F12, check the resulting behavior and then just run picom and check as well.

0BADC0DE · 2021-11-12 08:46:34

It looks like that disabling the compositor is making things better.
But I also get higher CPU loads ...

seth · 2021-11-12 09:47:36

That information is a bit sparse… higker CPU in what when doing what? And what is "better"?

0BADC0DE · 2021-11-12 09:53:42

seth wrote:

That information is a bit sparse… higker CPU in what when doing what? And what is "better"?

It looks like X is not as slow as it is when the compositor is enabled: opening a konsole is almost instantaneous.
On average, during the call I get higher CPU loads (seen with htop) than when having the compositor enabled.

seth · 2021-11-12 14:08:23

On average, during the call I get higher CPU loads (seen with htop)

Yes, but in what process? …
Did you meanwhile also check picom?

0BADC0DE · 2021-11-12 14:37:35

seth wrote:

On average, during the call I get higher CPU loads (seen with htop)
Yes, but in what process? …

None of the processes appears to be running at any time, but "htop" (of course, about 2%) and sometimes one of the "vivaldi-bin" process (1% - 3% for normal activity, up to 100+% [!] when doing video stuff).

All other processes are just "sleeping", there included kwin_x11, konsole, Xorg and all other KDE-related processes.
Xorg can go up to 10%, but it's never shown as running.

The overall CPU load is below 10% and goes up to 40% with MS Teams or Google Meet streaming a video, that is when I see the system crippled.
At that time the processes are almost all vivaldi browsers processes.
Loadavg stays all the time below 4 (I have 8 threads) unless I start compilations.

This is why I don't think it's the CPU load to cripple my PC!
If I had CPU at 100% with loadavg >=8, then I would blame the processes.
But this is not the case.

Spotting the culprit seems to be not that trivial.
And this is why I point my finger at some race condition or bottleneck in X/KDE: cpu has still power to spend, but is not being asked to by processes.

seth wrote:

Did you meanwhile also check picom?

Not yet, as this is my daily runner and I need to wait until EoD to fiddle with it! ;-)

Last edited by 0BADC0DE (2021-11-12 14:41:30)

seth · 2021-11-12 14:57:10

refusing to use hardware accelerated video decoding

If the compositor stalls the server/swap intervals, the browsers will have to decode less video and require less CPU for that.

Unfortunately the accelerated vide decoding support by browser versions for linux is beyond crap - I guess you're aware of the eternal chromium thread about this?
https://bbs.archlinux.org/viewtopic.php?id=244031

0BADC0DE · 2021-11-12 15:40:14

seth wrote:

refusing to use hardware accelerated video decoding
If the compositor stalls the server/swap intervals, the browsers will have to decode less video and require less CPU for that.
Unfortunately the accelerated vide decoding support by browser versions for linux is beyond crap - I guess you're aware of the eternal chromium thread about this?
https://bbs.archlinux.org/viewtopic.php?id=244031

I read some parts of that thread and I actually made my best (with your help) to get all green "hardware accelerated" messages in chrome, chromium and vivaldi.
I am going to live with that.
Hardware is being designed and supported only for Windows because they can keep it closed source or because they simply don't care.
I know that since the early days of Linux (for me it's 1992) when even a parallel port could be not supported.
I know that linux-ported software can be crappy because some programmers focus only on Windows.
This can still be OK to me.

What I cannot understand is the fact that (I think) I have plenty of computing resources and I/O capabilities and still I need to experience stuttering applications that basically do nothing, like a konsole instance starting up in 2 or 3 seconds when I am in Teams and in a zeroth of a second when not.
All with a system that's basically idling with more than 50% of CPU power available.
Is it the application?
Is it the graphics stack?
Is it the OS kernel?
Or some library?
I don't know.
But so do a lot of linux users like me.

0BADC0DE · 2021-11-17 07:43:54

seth wrote:

Did you meanwhile also check picom?

Trying with this "guide" which looked promising.
But when enabling the service I got:

Unit /home/user/.config/systemd/user/picom.service is added as a dependency to a non-existent unit xsession.target

It doesn't start.
If I start it manually with

/usr/bin/picom --experimental-backends

[ 17/11/2021 08:38:07.349 session_init FATAL ERROR ] Another composite manager is already running

it complains that kwin_x11 is still there.
So I kill kwin, start picom and then kwin again.
I don't see any change besides the X output in konsole being slow even without Teams/Meet.
I think I am using the wrong configuration.

It's not clear (to me at least) how to "replace" kwin with picom.
Do you have any hint/guide/link?

In the meantime I am also testing kwinft.

Last edited by 0BADC0DE (2021-11-17 07:55:12)

0BADC0DE · 2021-11-17 10:41:36

0BADC0DE wrote:

In the meantime I am also testing kwinft.

It seems I fixed the performance issue by switching to kwinft.
I need to keep a closer look to this situation, but that seems to be a promising way.

For the records, I have read about a KDE dev complaining about kwin being "in this state". Two years ago!

0BADC0DE · 2021-11-18 17:54:45

[UPDATE]
It is not clear whether kwinft fixes the problem or not.
From time to time I still see graphical applications lagging, especially after a few hours of work.
Maybe there's s a memory leak. I don't know.
Will try again with picom, now.

Arch Linux

#1 2021-11-11 14:56:03

Slow X when using Chrome/Chromium/Vivaldi: take 2

#2 2021-11-11 21:45:37

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#3 2021-11-12 07:53:29

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#4 2021-11-12 08:05:38

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#5 2021-11-12 08:46:34

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#6 2021-11-12 09:47:36

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#7 2021-11-12 09:53:42

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#8 2021-11-12 14:08:23

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#9 2021-11-12 14:37:35

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#10 2021-11-12 14:57:10

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#11 2021-11-12 15:40:14

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#12 2021-11-17 07:43:54

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#13 2021-11-17 10:41:36

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

#14 2021-11-18 17:54:45

Re: Slow X when using Chrome/Chromium/Vivaldi: take 2

Board footer