Bug 373368 - Spurious XCB Events causing high CPU
Summary: Spurious XCB Events causing high CPU
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.8.4
Platform: OpenSUSE Linux
: NOR major
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-06 20:22 UTC by René Krell
Modified: 2021-03-15 13:09 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Compressed output of valgrind --tool=callgrind --instr-atstart=no plasmashell for a few minutes after starting callgrind_control -i o (934.23 KB, application/gzip)
2016-12-07 13:35 UTC, René Krell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description René Krell 2016-12-06 20:22:06 UTC
KMail 5.3.3 (QtWebEngine), OpenSUSE Tumbleweed, Linux (x86_64) release 4.8.12-1-default:

Kmail is very slow when navigating between messages in the message list.
I have two accounts - an IMAP account (Activated Download all messages for offline use) and a Local Folders account.

To be sure this is no migration problem from KDE 4 I stopped KMail and Akonadi and removed the following folders and files:
~/.local/share/akonadi
~/.config/akonadi
~/.kde4/share/config/akonadi*
After that I restarted Akonadi and resynchronized the account again.
Thus, this should be a clean state.

When having synchronized all messages after the above cleanup action the problem reoccurs again:
I click on several messages in the message list, marking a new message in the message list freezes KMail for several seconds before the new message is shown in the message window.
This behavior happened from my point of view since the QtWebEngine has been introduced as message viewer.

Because I've read about multi-threading problems of Nouveau, I tried also the native NVidia driver, no change so far.
Comment 1 René Krell 2016-12-07 10:16:52 UTC
Important addition: This problem doesn't happen right after system start, but some time after using KMail (after several seconds, minutes or even hours). At the moment I can't see it, but when it happens the notebook's fan is running on higher speed, probably due to a high CPU load. As soon as the problem occurs, KMail doesn't recover from it, so the high load remains instant until the next system restart.

I nobody can reproduce this, please give me some hints what outputs to generate and provide, and what to do else to help analyzing.
Comment 2 René Krell 2016-12-07 10:20:17 UTC
The only process I saw with a high load during reproducing the problem was the baloo_file_extractor. After that I switched off Search -> File Search -> [ ] Enable File Search.

Deactivating the Baloo File Extractor might be way how to avoid the issue reported here, I'll watch this several days.
Comment 3 René Krell 2016-12-07 10:58:55 UTC
Sorry, that was to fast.

Baloo isn't the cause. I run into this problem again with deactivated File Search, but now I have plasmashell at high load:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3392 rkrell    20   0  0,255t 471020 187628 S 115,3 1,456  33:34.98 plasmashell

There is no comparable process in this situation with such a high CPU load.
Now even restarting KMail doesn't help.

Navigating between messages is almost unresponsive in both accounts, IMAP and Local Folders.
Comment 4 René Krell 2016-12-07 12:19:05 UTC
I'm currently keeping plasmashell running in valgrind according to this comment: https://forum.kde.org/viewtopic.php?f=289&t=121533&sid=7ab1403c4fedc79c23d4cadac1e09fd3&start=45#p343228
and waiting for plasmashell to fall into the high CPU load again, which is apparently the reason for the unresponsiveness of KMail. As soon as this will be the case I try to send some kcachegrind dump from it to get this issue to the right direction.
Comment 5 René Krell 2016-12-07 13:35:22 UTC
Created attachment 102662 [details]
Compressed output of valgrind --tool=callgrind --instr-atstart=no plasmashell for a few minutes after starting callgrind_control -i o

Added the compressed output of 'valgrind --tool=callgrind --instr-atstart=no plasmashell' for a few minutes after starting 'callgrind_control -i o'.

I started callgrind_control when kmail started to be unresponsive, including the rest of the plasmashell.

I'm not able to interpret the output shown in kcachegrind.
Can someone look at this, please?
Comment 6 René Krell 2016-12-07 13:42:49 UTC
This seems to become a plasmashell issue.
Comment 7 David Edmundson 2017-01-13 09:35:33 UTC
Rene, had a look 

Log shows we're receiving a ridiculous number of X events. 674603 in fact.
Assuming "several minutes" == 3 minutes, that's 3743 events per second, which is a sign that something is going wrong.

This matches something seen in one of the other generic high CPU threads.
Comment 8 René Krell 2017-01-13 10:02:39 UTC
(In reply to David Edmundson from comment #7)
> Rene, had a look 
> 
> Log shows we're receiving a ridiculous number of X events. 674603 in fact.
> Assuming "several minutes" == 3 minutes, that's 3743 events per second,
> which is a sign that something is going wrong.
> 
> This matches something seen in one of the other generic high CPU threads.

Edmund, thanks.
I saw just this issue: Bug 356479. Is there the same cause?
Most times this happened during sleep/hibernation mode, but not always.
I'm now at 5.8.5 (OpenSUSE Tumbleweed RPMs), and the problem hasn't appeared a long time here since updating. Maybe just accidentally, or has it been already fixed?
Comment 9 bjoernv 2017-01-13 10:07:34 UTC
I see this bug every day on the same Tumbleweed version
Comment 10 David Edmundson 2017-01-13 10:13:57 UTC
>I saw just this issue: Bug 356479. Is there the same cause?


See comment #90 in that thread.
It was the same cause, then that bug came to be talking about something else.
Comment 11 René Krell 2017-01-13 16:23:51 UTC
(In reply to bjoernv from comment #9)
> I see this bug every day on the same Tumbleweed version

You're right, right now I got the problem again with 5.8.5, just after "heavily using" the system (many Java processes and IDE in use). So this is definitely not fixed in 5.8.5.
Comment 12 David Edmundson 2017-07-08 15:06:46 UTC
*** Bug 381608 has been marked as a duplicate of this bug. ***
Comment 13 Lars Ivar Igesund 2017-08-07 16:47:38 UTC
I'm on Kubuntu 17.04 with Plasmashell 5.9.4. I just installed this, and am copying over files from an old PC using Krusader and fish://.

top shows a plasmashell process running at 108% (this is a 4 core with HT, i7-7700HQ, Dell Precision 5520 originally delivered with Ubuntu 16.04).

As far as I can tell, I have two animations, a fast spinner in the system tray and a slow one on the Krusader item in the taskbar.

I saw from some other bug that there was a dedicated issue for plasmashell CPU issues when doing file copying, but apparently it was tied to plasma4, so I'll comment here for now.

Anything I can do to help investigate? The current job says there is about 8 hours left... After that I think I'm mostly done with the file moving for now.
Comment 14 Michail Vourlakos 2017-08-09 01:26:44 UTC
I have the same issue(high cpu usage) when copying files, the BusyIndicator in the systray goes like crazy. Removing the systray and thus the mentioned animation and copying afterwards the same big file fixes the issue.

More details: In my system the same thing happens also with Discover. The BusyIndicators go like crazy and the cpu usage goes to maximum...

My system is Neon with plasma 5.10.4 and my graphic card is NVidia with proprietary drivers.
Comment 15 Michail Vourlakos 2017-08-09 01:29:45 UTC
Ok, I can confirm further... You dont have to remove the systray totally to fix this issue. The user can just disable the Notifications (that show the previous BusyIndicator) from the systray.
Comment 16 Edward Kigwana 2017-10-20 17:27:00 UTC
On my workstation with opengl I do not have this issue. In my VMs and on a target system without opengl (modesetting) atom bay trail cpu usage is so excessive that the interface starts glitching almost as though I was trying to run plasma on an i386@25 MHz. I can see the drawing sequences.

Editing /usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationIcon.qml and setting PlasmaComponents.BusyIndicator { running: active } to PlasmaComponents.BusyIndicator { running: false } and everything goes back to what I'd expect. On a side note sddm also has high CPU usage on the VM and the the Intel atom system. This issue appears for me on systems using the xrender code paths and when QML is involved it seems.
Comment 17 Michail Vourlakos 2017-10-20 17:34:32 UTC
To add more info, in my system this must be totally related to NVidia proprietary drivers.


Crazy thing is when Latte is using only one dock all the animations are played very fast! When there are two docks the animations return to normal speed. This is either broken drivers or qt/qml issue.
Comment 18 Alexander Potashev 2018-11-07 01:19:40 UTC
(In reply to Michail Vourlakos from comment #14)
> I have the same issue(high cpu usage) when copying files, the BusyIndicator
> in the systray goes like crazy.

Same here with Plasma 5.13.5 on Fedora 28.
Comment 19 Nate Graham 2021-03-09 03:52:35 UTC
Is anyone still seeing this issue in a recent Plasma version?
Comment 20 René Krell 2021-03-15 11:27:02 UTC
(In reply to Nate Graham from comment #19)
> Is anyone still seeing this issue in a recent Plasma version?

I haven't used KDE / KMail since 07/2017, I'm not able to update the state of the issue in current versions. From my point of view it is not interesting any longer. Maybe anybody else around? Otherwise this can be closed.
Comment 21 Lars Ivar Igesund 2021-03-15 13:02:04 UTC
I'm currently at Kubuntu 20.04, and also a newer Precision (5530) than the one I reported from last time. I don't think I've seen this issue come up again, so feel free to close on my part.