Bug 396345 - high cpu activity after upgrade from 5.12 to 5.13
Summary: high cpu activity after upgrade from 5.12 to 5.13
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.13.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-09 17:53 UTC by john Terragon
Modified: 2019-02-22 14:03 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
support info (5.79 KB, text/plain)
2018-07-09 20:51 UTC, john Terragon
Details
events for the activation of one firefox window (2.73 KB, text/plain)
2018-07-11 12:40 UTC, john Terragon
Details
events 5.12 (2.72 KB, text/plain)
2018-07-12 09:19 UTC, john Terragon
Details
events 5.13 (2.72 KB, text/plain)
2018-07-12 09:19 UTC, john Terragon
Details
props 5.12 (52.21 KB, text/plain)
2018-07-12 10:58 UTC, john Terragon
Details
props 5.13 (52.21 KB, text/plain)
2018-07-12 10:59 UTC, john Terragon
Details
props before (52.21 KB, text/plain)
2018-07-12 19:08 UTC, john Terragon
Details
props after (52.21 KB, text/plain)
2018-07-12 19:09 UTC, john Terragon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description john Terragon 2018-07-09 17:53:01 UTC
After my last system upgrade (debian sid) I've noticed a large increase in cpu activity by kwin. It seems to be related to the number of windows open. With, let's say, 30 windows open with kwin 5.12 I would see a steady 6 to 8 % cpu activity. Under the same exact conditions (not only the same number of windows but the very same set of windows) with kwin 5.13.2 I see a steady 36 to over 40 % cpu activity.


To isolate the problem, I've re-upgraded my system but this time I've kept  plasma 5.12 (and all the rest of kde stack: kf 5.46 etc). And the cpu activity is the usual 6 to 8%. So it does seem to be a problem related with kde and not with other software involved in the system upgrade (say, some part of x.org).


Is there maybe some new effect or something in plasma 5.13 that wasn't there in 5.12 and that I can try to disable to see if it's the culprit?

I'm using the opengl 2 backend. With opengl 3 it doesn't get any better. With Xrender it goes back to 6% cpu usage but of course it's not really smooth...
Comment 1 Martin Flöser 2018-07-09 19:44:04 UTC
Please provide the output of qdbus org.kde.KWin /KWin supportInformation
Comment 2 john Terragon 2018-07-09 20:51:11 UTC
Created attachment 113852 [details]
support info

Here it is.
Comment 3 Martin Flöser 2018-07-10 04:40:11 UTC
Please try disabling the blue effect
Comment 4 john Terragon 2018-07-10 08:38:07 UTC
Disabling the blu effect brings down the cpu usage by about 7%, which leaves it still above 30. 


And, btw, the only things that the blur effects blurs are the plasma decorations. Windows are not blurred, not even when they become semi-transparent when I drag them around. 


Another possible clue: 30 dolphin windows do not cause kwin to use much cpu, 30 firefox windows (and all pretty much static, that is without any change of the content like in ads, animation etc) cause the 40% cpu activity.


Right now we are at 80% cpu activity for kwin!
Also firefox seems to have higher cpu activity (higher than it has under 5.12).
Comment 5 Martin Flöser 2018-07-10 16:32:19 UTC
I see, so the problem is probably with firefox, not with KWin. KWin is just a victim of the stupid things firefox does. You can use xev -id <firefox window id> to monitor which events it creates. I assume it's constantly updating e.g. window title.
Comment 6 john Terragon 2018-07-10 18:52:54 UTC
If that's the reason, why doesn't firefox "victimize" kwin 5.12?
I have now two root filesystems (I use btrfs). Both of them have the same packages and at the same versions. Except one root has plasma 5.12 and the other has plasma 5.13.
And the problem is only with plasma 5.13...
Comment 7 Martin Flöser 2018-07-10 20:04:51 UTC
If we know which property causes the issue, then we can look into what changed in KWin.
Comment 8 john Terragon 2018-07-10 20:10:27 UTC
I wrote the following before reading your new comment (and I got a "mid air collision" from the bugtracker when I tried to post it :) ):


-----------------------------------------------------------------
Anyways, I went ahead and tried xev. So, I did the following:


1) wmctrl -lp to get all the winids of firefox's windows


2) xev -id on each and everyone of them (just to be sure)


When I do "xev -id <somewindid>" xev just stand there without reporting anything which I guess means the window <somewinid> isn't generating any event, right?


Anything else I can try?
Comment 9 john Terragon 2018-07-10 20:14:22 UTC
And, if I move the pointer on and off any firefox window when I'm xev'ing one of them, then xev says

ColormapNotify event, serial 18, synthetic NO, window 0x600007b,
    colormap 0x6000002, new NO, state ColormapInstalled

ColormapNotify event, serial 18, synthetic NO, window 0x600007b,
    colormap 0x6000002, new NO, state ColormapUninstalled

Don't know if it's relevant.
Comment 10 Martin Flöser 2018-07-11 04:52:57 UTC
try to activate a firefox window. I get significantly more events when doing that.
Comment 11 john Terragon 2018-07-11 12:40:54 UTC
Created attachment 113888 [details]
events for the activation of one firefox window

You can find the events in the attachment.

I have that wm setting that give focus to the window under the pointer
 and the events that you see in the file have been generated by


1) moving the cursor on the window

2) clicking on the window

3) moving the cursor on another window
Comment 12 Martin Flöser 2018-07-11 17:11:45 UTC
It changes WM_HINTS property. I need to check, but my feeling is that this is not allowed.
Comment 13 john Terragon 2018-07-11 22:25:18 UTC
Isn't that something that an application can set/change to give a suggestion to the wm (the hint part...)?

Anyways, let me know if there's something else I can try. I sync'ed the two roots with another system, a desktop one (and more recent, a 4770k I think). I see the same behavior, it's about triple the cpu usage by kwin 5.13 wrt to 5.12.
Comment 14 Martin Flöser 2018-07-12 04:21:57 UTC
Can you compare the wm_hints property?
Comment 15 john Terragon 2018-07-12 09:19:16 UTC
Created attachment 113894 [details]
events 5.12
Comment 16 john Terragon 2018-07-12 09:19:51 UTC
Created attachment 113895 [details]
events 5.13
Comment 17 john Terragon 2018-07-12 09:21:06 UTC
I assumed you wanted the events for both 5.12 and 5.13. You can find them in the attachments above. They have been generated by the same firefox window.
Comment 18 john Terragon 2018-07-12 10:58:46 UTC
Created attachment 113896 [details]
props 5.12
Comment 19 john Terragon 2018-07-12 10:59:13 UTC
Created attachment 113897 [details]
props 5.13
Comment 20 john Terragon 2018-07-12 11:00:49 UTC
Sorry, you probably wanted the props of one firefox window. I used xprop. You can find the props, ver 5.12 and 5.13, for the same window in the attachments above.
Comment 21 Martin Flöser 2018-07-12 14:42:36 UTC
Actually I wanted the props of same window before and after activating it.
Comment 22 john Terragon 2018-07-12 19:08:41 UTC
Created attachment 113902 [details]
props before
Comment 23 john Terragon 2018-07-12 19:09:01 UTC
Created attachment 113903 [details]
props after
Comment 24 Anton 2018-09-12 09:10:31 UTC
I have the same issue after updating from 5.12 to 5.13.
I found that switching to Xrender lowers my CPU usage to 2%-3%.
Comment 25 Vlad Zahorodnii 2019-02-22 14:03:57 UTC
Marking as worksforme because there wasn't any activity for a while and also because cpu usage is normal on my machine.