When the debugger attaches, it stops the process (so you can interact on the present stack position) - thus the CPU drop (the process is stopped and doesn't consume any COU). You need to "continue" it (and press ctrl+c to stop it again)

gdb is however rarely useful to figure what causes CPU load (unless it's a life-lock
The tool of choice is

Code: Select all

pkill plasmashell; sleep 1; valgrind --tool=callgrind --instr-atstart=no plasmashell


This will start plasmashell, some "valgrind" process will eat all your CPU (that's ok) and once you see plasmashell getting "too busy" again, you run

Code: Select all

callgrind_control -i on


what activates callgrind and makes it measure things.

After a while you can just quit valgrind (press ctrl+c in the konsole tab you used to start it) and it will generate some "callgrind.out.123456" which you can inspect with kcachegrind (or your favorite text editor, if you're some kind of masochist =)

Afaiu the usual suspect is now the fullscreen runner, though.

luebking wrote:This will start plasmashell, some "valgrind" process will eat all your CPU (that's ok) and once you see plasmashell getting "too busy" again, you run

I see no plasmashell in the process list; does it mean it's being run in the same process valgrind runs?
I'm not sure what you mean by "will eat all your CPU". Valgrind process takes about 10%.

luebking wrote:After a while you can just quit valgrind (press ctrl+c in the konsole tab you used to start it) and it will generate some "callgrind.out.123456" which you can inspect with kcachegrind (or your favorite text editor, if you're some kind of masochist =)

I'm not able to interpret what I see in kcachegrind. Should I attach output file here?

luebking wrote:Afaiu the usual suspect is now the fullscreen runner, though.

What's fullscreen runner?

Thanks for all hints. Are they to be found on some KDE help pages?

Piotr Dobrogost wrote:I see no plasmashell in the process list; does it mean it's being run in the same process valgrind runs?

Yes

Piotr Dobrogost wrote:I'm not sure what you mean by "will eat all your CPU". Valgrind process takes about 10%.

After it settled and before you activated it, yes. Otherwise it (resp. callgrind) will require quite some resources.

Piotr Dobrogost wrote:I'm not able to interpret what I see in kcachegrind. Should I attach output file here?

You can upload it seomewhere (it's typically HUGE).

Piotr Dobrogost wrote:What's fullscreen runner?

Fullscreen application launcher, sometimes referred to as dashboard and whatnot. Looks like you desktop was a smartphone

Piotr Dobrogost wrote:Are they to be found on some KDE help pages?

That valgrind is a profiler and gdb is not??

Thank you for all your answers.

luebking wrote:You can upload it seomewhere (it's typically HUGE).

I put it at https://www.dropbox.com/s/5btzavekrmyqn ... 11431?dl=0
Could you please take a look?

luebking wrote:That valgrind is a profiler and gdb is not??

No, information on how to debug high CPU usage.

Perhaps interesting - At least for some users, part of this problem is caused by a Frameworks issue, see this bugzilla issue. The good news is that this commit should fix the problem. Coming to the next Frameworks release. For those not on a rolling release, bug your distro for a backport or - try a rolling release because it is awesome

Another potential reason lies in GPU driver issues, especially on NVIDIA. That one should be fixed in an upcoming NVIDIA driver update, see this bugzilla issue, this Qt bug and and this nvidia comment.

A possible work-around is to create a script with "export QSG_RENDER_LOOP=basic" and add it as auto-start before the KDE login. This only helps with the NVIDIA problem, afaik.

Please notice that
a) triple buffering doesn't block on controlled swaps
b) later nvidia drivers do not even block on double buffered controlled swaps (please don't ask: I have no idea "how", see https://bugs.kde.org/show_bug.cgi?id=346275)
c) uncapped buffer flooding in triple buffered environments leads to "laggy" behavior (what many gamers think the inevitable input lagging is; it's not. it's simply a dumb game engine. The actual additional frame of input lag is not really notable for human beings on 60fps

The second swap *may* block (haven't tested, but to avoid the "lagging", the driver could simply discard the frame in the pipe. Nothing will then ever block), but you're still at twice the required CPU load then.

No idea what the final impact is, but I'd not "rely" on fixing optimus swapcontrol to resolve the problem.
Desktop != Egoshooter -> don't paint as fast as you can, but as fast as you need.

I'm also having this problem. I'm running 15.10 on an XH81 barebone with i3 4370 process, i.e. HD 4600 graphics.

gdb output:

Code: Select all

(gdb) bt
#0  0x00007f7c0d98db28 in QQuickShaderEffectSource::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#1  0x00007f7c0d8a1dd7 in QQuickWindowPrivate::updateDirtyNode(QQuickItem*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#2  0x00007f7c0d8a287b in QQuickWindowPrivate::updateDirtyNodes() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#3  0x00007f7c0d8a2eee in QQuickWindowPrivate::syncSceneGraph() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#4  0x00007f7c0d873c40 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#5  0x00007f7c0d8746d1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x00007f7c0b326b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007f7c0b32c230 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007f7c0a848f1b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007f7c0a89f09d in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f7c0a89f5a1 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f7c06d22ff7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f7c06d23250 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f7c06d232fc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f7c0a8a027f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007f7c0a84675a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007f7c0a84e2cc in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00000000004322c3 in main ()


kcachegrind (after the valgrind, callgrind_control method advised above) confirms that 100% of CPU is spent in QQuickShaderEffectSource::updatePaintNode.

I disabled all desktop effects, but the problem reliable shows after the screen enters energy saving (or some time after, I've only observed it after waking up the screen).
Restarting plasmashell makes everything happy until the next screen sleep...

Any advice welcome.

I have the same issue.
When I add cpu and network monitor widget on Plasma Desktop, CPU load is always about 25-30%.

This thread was opened in June 2014. Now January 2016 and the problem isn't fixed yet. How could that be possible?

I found a workaround here: https://bugs.kde.org/show_bug.cgi?id=311799.

Open file /usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationIcon.qml

Search for line "running: visible" in "PlasmaComponents.BusyIndicator" section and change it in "running: false".

That seems to work for me. Now 1-2% cpu load for plasmashell process with cpu and network monitor on right bar in Plasma Desktop.

I have same problem with dashboard plasmoid

I have a similar problem tough the CPU usage is around 10 - 15 even with everything in idle. How can I debug the behavior? If it's a plasmoid how can I detect which one is it? It seems that if I reset the plasma settings, the cpu is 1-2% but after a while it gets back to high cpu. Any known bug with icon only task manger?

only thing I can think of is to remove plasmoids 1 by 1 until the culprit is found, alternately start with a fresh desktop (or as a new user).

I might start with monitoring widgets because they would always be doing some kind of processing since they are real time

hi !

i'd the same problem , plasmashell keeps eatting cpu until it frezes the machine ,

i simply removed everything inside autostart folder and it worked fine!

the fact that i have a lot of autostart scripts i didn't trace yet which one is causing problems for plasmashell

In my case it used about 15% of CPU in a 4-core system.
After quitting Skype, plasmashell uses a negligible amount of CPU.

Unfortunately i can only confirm that the bug still present in plasmashell 5.7.4. Running on fully updated Debian Stretch,

The bug occurs every time when a file is being copied using Dolphin. Copying of 4Gb movie loads one of 4 cpu cores. Same problem on my 2(4) cores laptop -- copying or setting up wifi eats up CPU. Let me know if I can provide additional info.