| Summary: | Spurious XCB Events causing high CPU | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | René Krell <renda.krell> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | aspotashev, bhush94, bjoernv, ekigwana, joh82875, kfunk, larsivar, mvourlakos, nate, plasma-bugs, quelque_ri1 |
| Priority: | NOR | ||
| Version: | 5.8.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Compressed output of valgrind --tool=callgrind --instr-atstart=no plasmashell for a few minutes after starting callgrind_control -i o | ||
|
Description
René Krell
2016-12-06 20:22:06 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. 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. 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. 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. 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?
This seems to become a plasmashell issue. 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. (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? I see this bug every day on the same Tumbleweed version >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. (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. *** Bug 381608 has been marked as a duplicate of this bug. *** 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. 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. 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. 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.
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. (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. Is anyone still seeing this issue in a recent Plasma version? (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. 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. |