If your bug is marked as a duplicate as this it means it's a bug about high CPU with no other information, which makes it not very useful. The following links may also be useful: https://bugreports.qt.io/browse/QTBUG-45959 https://bugs.kde.org/show_bug.cgi?id=311799 https://bugs.kde.org/show_bug.cgi?id=373368
*** Bug 372839 has been marked as a duplicate of this bug. ***
*** Bug 377953 has been marked as a duplicate of this bug. ***
*** Bug 375044 has been marked as a duplicate of this bug. ***
*** Bug 377276 has been marked as a duplicate of this bug. ***
It would be more useful to say what about those links are useful - leaving just the links doesn't seem like an optimal way to get people to improve their reports. That being said, I did the legwork of finding relevant posts and collecting the trace - see attachment. I must admit I'm amazed the KDE people can't solve panel animations once and for good since 2013...
Created attachment 104719 [details] callgrind output Compressed output of about 20-30s of running `valgrind --tool=callgrind --instr-atstart=no plasmashell` while copying a file over network with Dolphin.
(In reply to David Edmundson from comment #0) > If your bug is marked as a duplicate as this it means it's a bug about high > CPU with no other information, which makes it not very useful. So can you use the log that kdde.rhn provided?
That trace has a few interesting things in it: - we're still losing a tonne of time (30% or so) processing X events. We're getting over 670,000 of them in 30 seconds. They end up costing a lot because it then goes through all the nativeEventFitlers in KDE code that do a somewhat pointless string compare.. but the root question is what the hell are these events, and where's the real bug? That's come up before: https://bugs.kde.org/show_bug.cgi?id=373368 - we're losing 7% in some X window updating it's properties 313 times in 30 seconds. I've not seen that before. That window then propogates through the task manager changing, which builds up. Qt 5.9 will fix a lof of that propogation but again the root question which window is changing and what and why? Can you put some debug in KWidnwSystem::windowChanged and find out? Once we know we can break that out into a new bug. - we're losing another 15% in some JS evaluation. It's quite possibly related to the issue above; the evaluation needs to have some trigger. QML profiler could confirm that.
> Can you put some debug in KWidnwSystem::windowChanged and find out? How to do that? Is it possible to do that without recompiling, e.g. some LD_PRELOAD trick? If not, what's the minimal set of things and easiest way to recompile? You explained where 30% + 15% CPU time goes, do you have any ideas as to where the other 50-55% goes? 50% CPU usage while copying is still very bad.
*** Bug 376146 has been marked as a duplicate of this bug. ***
Recompiling is the quickest way. You could do probably do it with GDB skills, but frankly it's not worth it especially as we don't want to interrupt the processing as that could skew results. if you're on Debian/Ubuntu apt-get build whateverPackageKWindowSystemIsIn apt-get source whateverPackageKWindowSystemIsIn make the changes fakeroot debian/rules binary sudo dpkg -i ../*.deb as for the debug in kwindowsystem.cpp under if (dirtyProperties || dirtyProperties2) { add qDebug() << "DAVE " << eventWindow << dirtyProperties << dirtyProperties2; For other distros check out their own guides, if you can't figure it out, let me know what you're on and I'll get someone from that distro to help. Get debug by running plasmashell from a konsole, you're also going to then have to turn the window ID into something useful by running "xprop -id SOMENUMBERHERE" As for the remaining CPU, it's a bit hard to interpret something. Not everything is very readable, especially when you have an event queue. The biggest issue is it's quite easy to fall into traps like micro-optimising a method that gets called a lot rather than figuring out why it gets called a lot, which is why I can't just read a log and do something about it, it requires deeper investigation. Also, thanks in advance.
I found no "if (dirtyProperties || dirtyProperties2) {" line in my kwindowsystem.cpp, but when I run plasmashell with GALLIUM_HUD=fps, it shows up that notifications are drawing with 200+ frames per second. Maybe it's good idea to draw them vsynced in the first place?
Also, the interesting thing i noticed: 1. I've started copying a large file (60 Gbytes), cpu load for plasmashell was 125% 2. I killed plasmashell, and restarted it again. cpu-load was almost zero. 3. I clicked on notifications widget, cpu-load jumped to 75% 4. I clicked on "details" triangle in notifications widget several time, cpu load upped to 105%-110%.
What do you mean exactly by "notifications are drawing at 200fps"? and yes, it should be vsynced, there's code to do it (in Qt) There's a nice line in the Qt documentation on that: >Note: The threaded and windows render loops rely on the OpenGL implementation for throttling by requesting a swap interval of 1. Some graphics drivers allow users to override this setting and turn it off, ignoring Qt's request. Without blocking in the swap buffers operation (or elsewhere), the render loop will run animations too fast and spin the CPU at 100%. If a system is known to be unable to provide vsync-based throttling, use the basic render loop instead by setting QSG_RENDER_LOOP=basic in the environment. Though if you're on intel on X, you should be running on basic anyway. Can you run QSG_INFO=1 plasmashell but I also don't want to get distracted from the first thing we were actually doing: there are multiple kwindowsystem.cpp files, I meant ./platforms/xcb/kwindowsystem.cpp
Created attachment 104748 [details] QSG_INFO=1 plasmashell
I've uploaded output for QSG_INFO=1. As fps, it's what I see in on-screen fps counter if I run plasmashell with GALLIUM_HUD=fps variable set. Works only with gallium-based opengl drivers. Thank you for clarifying which kwindowsystem.cpp should be modified, I'll try to do it next weekend.
So that says we're using the basic driver, so I looked into how that chooses the frame rate which is all in the QSGAnimationDriver constructor, which is all based around the refresh rate of the primary screen at the time of the context launch. It then switches between that or a timer. That first part is obviously dependendent on your setup so could be interesting. Can you instead run: QT_LOGGING_RULES=qt.scenegraph.general.debug=true plasmashell
Created attachment 104761 [details] QT_LOGGING_RULES=qt.scenegraph.general.debug=true plasmashell >can you instead run: >QT_LOGGING_RULES=qt.scenegraph.general.debug=true plasmashell Here it is. Checked twice.
Urgh. Can you tell me your Qt version again? Maybe someone renamed the debug categories. @any other plasma dev, any idea why my line doesn't work for network723
#zypper info libqt5Core5 Loading repository data... Reading installed packages... Information for package libQt5Core5: ------------------------------------ Repository : openSUSE-42.2-Oss Name : libQt5Core5 Version : 5.6.1-2.1 Arch : x86_64 Vendor : openSUSE Installed Size : 4.9 MiB Installed : Yes Status : up-to-date Summary : Qt 5 Core Library Description : The Qt 5 Core library.
Ok so to follow up on that: - it'll just give the same info as we got from your QSG_INFO=1 run - the reason you don't have QSGAnimationDriver output is because basic render loop doesn't make one - which kinda makes sense we don't need to advance animations in the same thread we can just do it pre-rendering. - means we need a new lead In any case, for now lets focus on that kwindowsystem thing I asked for - then we can go back to vsync issues afterwards
I'm still waiting on that kwindowsystem information I asked for.
*** Bug 377583 has been marked as a duplicate of this bug. ***
Created attachment 104885 [details] plasmashell log with modified kwindowsystem.cpp Sorry, I forgot about it. Here is the log. I'm not sure what I should do with xprop and window IDs. If you need that info along with plasma terminal output, please explain better.
*** Bug 371889 has been marked as a duplicate of this bug. ***
It seems it wasn't any one window going mental. Over what timespan is this log for? 203423846 must have been the panel, we can see it updating its user time a lot We're updating all the window's icon geoemtries a lot, which means the task manager is resizing itself (QFlags(0x200000) but that's only 3 times. Can I assume you're your panel is not the full width and resizes when you get new windows? There's also 56 geoemtry updates from 10 windows, that's one of the few that will update the task manager. We can see that it might be worth batching some X window changes, it'll have some impact, but nothing astronomical. This assumes of course this trace has the same stuff happening as when you were running callgrind earlier...which I'm not too convinced of.
I did wait for several minutes. It's as close to callgrind as possible: I've opened the very same programs, started plasma and induced high cpu usage by clicking on plasma tray icon. So, 56 geometry updates is probably me clicking on show/hide button to trigger the bug.
*** Bug 379210 has been marked as a duplicate of this bug. ***
*** Bug 375457 has been marked as a duplicate of this bug. ***
I wonder if my report from re kwin_x11 belongs here too? https://bugs.kde.org/show_bug.cgi?id=378010
*** Bug 381608 has been marked as a duplicate of this bug. ***
*** Bug 381592 has been marked as a duplicate of this bug. ***
*** Bug 381817 has been marked as a duplicate of this bug. ***
Is there any workaround for this at the moment?
At the moment I just do 'killall plasmashell' to be able to work without the sound of a space shuttle taking of next to me.
See also https://bugs.kde.org/show_bug.cgi?id=379866#2 which I think may be what some people are seeing.
I think some of it may be caused by having multiple taskbars (some hidden). I largely alleviated the issue by deleting the plasmashell configuration and letting it create a fresh one. Seems like the plasma-workspace-5.8.7-1.fc24.x86_64 doesn't have the bug that creates unnecessary taskbars every time a screen is plugged in (don't know when it was fixed though). Still get between 6 and 12% CPU use (single core) of an i7-6600U just rendering 2 taskbars with static icons and two second-precision clocks...
How can we find out how many hidden ones there are?
Easy way, click on add widgets and you'll see the number in the circle
This seems to be the case for me, there are apparently seven taskbars on my system.
Split comment about multiple taskbars into here https://bugs.kde.org/show_bug.cgi?id=382221 Can anyone who has multiple taskbars (see #39) please provide the information requested at the top of that bug report.
*** Bug 381471 has been marked as a duplicate of this bug. ***
I also seem affected. OpenSuse Tumbleweed, up to date. After the 4th July Tumbleweed snapshot I experience high CPU usage (and probably also GPU), after 15 mins of Plasma usage flickering appears, high temperature. My current plasma5-workspace version is 5.10.3-1.2 libQt5Core5 version 5.9.1-1.1
*** Bug 382551 has been marked as a duplicate of this bug. ***
*** Bug 382618 has been marked as a duplicate of this bug. ***
*** Bug 381280 has been marked as a duplicate of this bug. ***
*** Bug 383227 has been marked as a duplicate of this bug. ***
After upgrading yesterday to the latest openSUSE Tumbleweed snapshot, the symptoms have disappeared for me! :) NO high CPU usage, NO flickering artifacts, NO overheat. Everything back to normal. I saw that there were a bunch of updates for Qt 5.9. I will report its exact version and build number this evening when I get home (if needed). Thx for the help.
Heya, Yes the Qt versions would be nice.
False flag, sorry! :( For some reason yesterday evening after the update (and a restart of course) the problem got solved. But today after boot I experience the same issue as before. I don't know what influences this. Anyway, my current Qt versions vary between 5.9.1-2.1 (e.g. libQt5Core5), 5.9.1-1.1 (e.g. libQt5X11Extras5) and 4.8.7-7.2 (e.g. libqt4), and also some others. I can provide the full list if required. - I would also like to emphasize that I experience heavy component flickering: I interact with a window resulting in state change so gets updated/redrawn but in the next moment it flickers back to the previous state for a few seconds, or it even gets frozen, etc. For example: -- I change windows (taskbar / ALT + Tab), but after a few moments for a few moments the old window gets displayed again. -- Tooltips will flicker or get frozen during animation. -- I delete some characters in a text editor, but for a few moments they get displayed again, etc. - kwin_X11, plasmashell and X (in this order) are using ~20-30% of CPU. - warm laptop openSUSE Tumbleweed (kwin5 version 5.10.4-1.1) on an Acer Aspire R13 R7-372T.
(In reply to Vetko from comment #50) > openSUSE Tumbleweed (kwin5 version 5.10.4-1.1) on an Acer Aspire R13 R7-372T. Intel Graphics? Are you using the intel kernel modesetting driver, or the classical Intel driver? Both do not work very well, but both seem to exhibit different quirks...
(In reply to Gunter Ohrner from comment #51) > Intel Graphics? Are you using the intel kernel modesetting driver, or the > classical Intel driver? > > Both do not work very well, but both seem to exhibit different quirks... the xf86-video-intel package is not installed, so I suppose I'm using the modesetting driver. (But I hadn't had any issues until a few weeks back..)
*** Bug 383956 has been marked as a duplicate of this bug. ***
Adding a comment here rather than opening a new bug, as I think this a duplicate of what is discussed here. I noticed that sometimes I have a mild, but constant, CPU usage of kwin_x11. I opened a post on Reddit about that and M. Gräßlin advised me to open a bug report about it against plasmashell: https://www.reddit.com/r/kde/comments/6wpvmr/kwin_is_always_the_top_of_top_cpu_usage/ Using his advice, I can confirm this high CPU usage of kwin_x11 is always linked to a constant and rapid repaint of plasmashell. What triggers this repaint is unknown to me. I suspected the Comics plasmoid, but I just had this exact behaviour even though I removed it and now only have "Folder View" plasmoids. One thing I noticed though, it that this repaint is very similar to the one I get when the Comics plasmoid was updating the content with the "circling animation". This triggered a repaint of the whole plasmashell. Sorry for this not very precise bug report, I did my best to pinpoint the origin of this, without success. I can provide more information with enough guidance. This is openSUSE Tumbleweed with Plasma 5.10.5.
Since upgrading to Fedora 25 with plasma-workspace-5.9.5.1-1.fc25, the CPU usage is acceptable: - idle CPU usage is <3% of one core - copying files does not change that significantly - CPU does not go through the root any longer This is on an Intel HD4000 GPU, with modesetting driver.
*** Bug 384663 has been marked as a duplicate of this bug. ***
I am also affected by high CPU and Memory related issues in plasmashell/kwin_x11. I got the feeling though that the high CPU was the system trying to find pages to swap, etc e.g dealing with the memory "leak" in plasmashell. My Linux debugging skills does not allow me to verify this suspicion. After reading this thread as well as other discussions (Kubuntuforums) I have now removed all but the most essential plasmoids. I will monitor but this is rather irksome.
Perhaps you may have a look here: https://bugs.kde.org/show_bug.cgi?id=381280#c15. Here I could reproduce a high cpu usage with the folderview widget showing activity-linked files (on two separate activities). After switching the activities I could trigger a constantly high cpu usage. under plasma 5.10.95 and frameworks 5.38
Hi ! I observed high plasma shell CPU usage (from 20% to 100%) after resuming on a laptop with an integrated GPU (hd 3000) + unused Nvidia GPU (610M). Restarting plasmashell fixed it. Using KDE Neon, plasma 5.10.x. Generally, resuming seems problematic on this machine, even with other DEs. But at least on Plasma it does resume everytime... Though it can take some time and induce this CPU usage. I'd be glad to help debug it ! (apart from it, Neon / Plasma really rule even on slow hardware :-)
*** Bug 375736 has been marked as a duplicate of this bug. ***
The issue went away for me! It's back now though after this happened: Downgrade: plasma-integration:amd64 (4:5.11.0-0neon+16.04+xenial+build58, 5.11.3-0neon+16.04+xenial+build64)
*** Bug 387223 has been marked as a duplicate of this bug. ***
(In reply to Vetko from comment #50) > - I would also like to emphasize that I experience heavy component > flickering: I interact with a window resulting in state change so gets > updated/redrawn but in the next moment it flickers back to the previous > state for a few seconds, or it even gets frozen, etc. > For example: > -- I change windows (taskbar / ALT + Tab), but after a few moments for a few > moments the old window gets displayed again. > -- Tooltips will flicker or get frozen during animation. > -- I delete some characters in a text editor, but for a few moments they get > displayed again, etc. I'm running Lenovo X220 (Intel HD3000, Sandy Bridge, Intel driver) and sometimes have the same issue. Do you use external monitor? Does it occur only if you plugged external monitor at least once since KDE start? If yes, can you confirm https://bugs.kde.org/show_bug.cgi?id=388759 It could be linked.
valdikss@gmail.com - this sounds like a kwin issue. Try doing `kwin --replace` and see if it goes away. Then perhaps it can be filed in the kwin category. I'm occasionally experiencing something similar on Ivy Bridge btw.
(In reply to kdebuac.rhn from comment #66) > valdikss@gmail.com - this sounds like a kwin issue. Try doing `kwin > --replace` and see if it goes away. Then perhaps it can be filed in the kwin > category. I'm occasionally experiencing something similar on Ivy Bridge btw. No, that's a plasmashell issue, probably linked to bug 388759. I just got this issue, and the symptoms are just like in 388759, but it did not involve resolution change or screen reconfiguration. It was probably because of high CPU load, I was compiling a project for several minutes and the CPU was 96°C. Restarting plasmashell fixed the issue.
(In reply to Mahendra Tallur from comment #60) > Hi ! I observed high plasma shell CPU usage (from 20% to 100%) after > resuming on a laptop with an integrated GPU (hd 3000) + unused Nvidia GPU > (610M). Restarting plasmashell fixed it. Using KDE Neon, plasma 5.10.x. > > Generally, resuming seems problematic on this machine, even with other DEs. > But at least on Plasma it does resume everytime... Though it can take some > time and induce this CPU usage. > > I'd be glad to help debug it ! > > (apart from it, Neon / Plasma really rule even on slow hardware :-) my laptop also is affected Laptop=Dell latitude E6510, RAM=8Gb, GPU=GT218 NVS 3100M, CPU=i7 Q 720 @ 1.60GHz: host=pla-3-TW, partition=suse2, OS=leap 42.3, DE=plasma 5.11.95, KDE frameworks 5.42.0, KDE applications 17.12.1, Kernel 4.4.104-39-default, nvidia drivers
and also my desktop pc: CPU (Processor):Intel Core i5-7400 4x3.00GHz 7th Kaby Lake, Mainboard:B250M MSI Pro-VDH (7A70-003R), Video Card (VGA Card) onBoard Graphic, System Memory (RAM):8GB Kingston DDR4-2400, SSD:240GB Western Digital WD Green M.2 running leap 42.3 with KDE when I boot it is fast and responsive, after one day staying on and with no operations by a user it becames slow and laggy, mouse is slow, selection is slow ecc, only reboot solve, and after reboot it start again to be responsive.
(In reply to pier andre from comment #69) As far as I can see, KDE Neon does not have commit 6990ae6c1bad32952e371fa72bee65a7af11c313 applied for qt5-qtdeclarative (Fedora's package naming, could be different in KDE Neon). Track it here: https://bugs.kde.org/show_bug.cgi?id=389218 If you can rebuild this package with the following patch: http://code.qt.io/cgit/qt/qtdeclarative.git/patch/?id=6990ae6c1bad32952e371fa72bee65a7af11c313 And see if it helps.
I can make plasmashell spike by doing this: 1) Open Dolphin and click Split 2) In right hand window sftp onto a server 3) Move a file from the left to the right window I wonder if this is related?
Git commit ec1931f7b2980a3cd445c09def1bb4a9b5ad607f by David Edmundson. Committed on 29/03/2018 at 14:38. Pushed by davidedmundson into branch 'master'. Batch window changes events on XCB Summary: In a log from someone talking about high CPU we can see get multiple X events for the same window as multiple events, but directly next to each other. This causes the TaskManager to process changes multiple times instead of just once which is a waste. An example is just pressing "enter" in konsole, which will pointlessly update the title. This causes problems for expensive app lookup and also QML performs text layouts immediately so any text changes cause quite large CPU usage if done more than 60fps; especially a task text resizing could result in resizing the entire panel. Something not relevant in kwin that also monitors these rolls. This class sits between KWindowSystem and XWindowTasksModel transparently buffering the changes. Related: bug 365317 Reviewers: #plasma, hein, broulik Reviewed By: #plasma, hein, broulik Subscribers: ngraham, cfeck, broulik, hein, graesslin, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D7481 M +1 -0 libtaskmanager/CMakeLists.txt M +0 -1 libtaskmanager/TODO.txt A +80 -0 libtaskmanager/xwindowsystemeventbatcher.cpp [License: BSD] A +51 -0 libtaskmanager/xwindowsystemeventbatcher.h [License: BSD] M +6 -5 libtaskmanager/xwindowtasksmodel.cpp https://commits.kde.org/plasma-workspace/ec1931f7b2980a3cd445c09def1bb4a9b5ad607f
*** Bug 353507 has been marked as a duplicate of this bug. ***
Closing since this isn't really actionable and doesn't help anyone to keep it open, unfortunately. Actionable bug reports can be investigated on a case-by-case basis.