Bug 345696 - when adding any monitor widget (CPU, MEM, NETWORK, I/O Disk) directly huge %CPU consomption with plasmashell process
Summary: when adding any monitor widget (CPU, MEM, NETWORK, I/O Disk) directly huge %C...
Status: RESOLVED DUPLICATE of bug 348385
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Arch Linux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Marco Martin
URL:
Keywords:
: 347148 347324 348411 349091 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-03-30 15:59 UTC by desaparecido
Modified: 2017-08-03 17:11 UTC (History)
43 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
strace with network monitor widget in panel (896.47 KB, text/plain)
2015-05-01 16:41 UTC, Patrick Auernig
Details
strace without network monitor widget (56.89 KB, text/plain)
2015-05-01 16:42 UTC, Patrick Auernig
Details
ltrace -c -f -C -L -l libdri* -l libxcb* (with CPU load monitor widget) (7.63 KB, text/plain)
2015-05-28 01:07 UTC, Ancoron
Details
ltrace -c -f -C -L -l libdri* -l libxcb* (without any widget) (7.93 KB, text/plain)
2015-05-28 01:07 UTC, Ancoron
Details

Note You need to log in before you can comment on or make changes to this bug.
Description desaparecido 2015-03-30 15:59:37 UTC
I use kf5 and plasma5 from git (via AUR pkgbuilds in Archlinux), and I added some system monitors and directly a high CPU consomption is plasmashell process has started (with a very loud sound of CPU's fan in my tower was really easy).  With HTOP some plasmashell process had 70%-90% of CPUs.

Reproducible: Always

Steps to Reproduce:
1.open terminal with htop command and plasmashell %CPU is 1% 
2.add any of system monitor widgets (cpu, mem, networks, I/O disk) and watch for changes in plasmashell process %CPU in htop (one by one)
3.deleting the widget and monitor changes in htop

Actual Results:  
before add the widgets plasmashell proc %CPU is 1%.
Add any of system monitor widgets (cpu, mem, networks, I/O disk) plasmashell %CPU is:
cpu mon = 88%
network mon = 20%
mem mon = 25%
I/O disk = 80%
And deleting the widget directly plasmashell %CPU is 1% again.

I use dual screen and is the same results adding in any screen.

Expected Results:  
than after add a widget the %CPU of plasmashell process stay with a normal CPU comsoption to have a stable system

I use Archlinux with linux 4.0rc6, KF5 and plasma5 git versions, GPU ATI Radeon HD 7970 with Catalyst driver version 15.3, Dual screen.
Comment 1 Andrew Gaydenko 2015-03-30 22:54:50 UTC
It is funny I have similar problem with all-last-stable versions of Arch, x86_64, nouveau/NV98). CPU eating is rising during a session up to almost a core (i5 is in use). After removing  System Load Viewer from the panel, plasmashell eating drops to 1-2%.  The issue doesn't depend on Compositing (on or off), so I guess it isn't driver/opengl or similar problem. I would name the last one as "CPU leak" :)

Also the issue takes place on file operations - notification icon is animating (rotating) resulting in eating almost additional CPU core.
Comment 2 Hervé Le Roy 2015-04-24 08:48:14 UTC
Same issue here with Kubuntu 15.04 with Plasma 5.3 beta (from kubuntu-ppa/beta).
Comment 3 Patrick Auernig 2015-05-01 16:34:23 UTC
Same issue here on Arch Linux x86_64

The desktop widgets increase CPU usage by around 20-30%

If put into a panel, the process monitor is doing kinda alright (~2% just for the monitor).
The network monitor though pushes my CPU usage to 50, sometimes over 100%.
Comment 4 Patrick Auernig 2015-05-01 16:41:38 UTC
Created attachment 92357 [details]
strace with network monitor widget in panel

don't know if this is useful
Comment 5 Patrick Auernig 2015-05-01 16:42:20 UTC
Created attachment 92358 [details]
strace without network monitor widget
Comment 6 Patrick Auernig 2015-05-01 16:47:30 UTC
Looks like this happens with all widgets that are using the graph
Comment 7 Andrew Gaydenko 2015-05-01 17:26:47 UTC
Have we got the stage to change bug status? I guess, we have sufficient amount of confirmations..
Comment 8 Aleix Pol 2015-05-02 01:10:32 UTC
I can reproduce as well.
Comment 9 FBrown 2015-05-02 06:06:29 UTC
Also reproducible here on kubuntu 15.04 with Plasma 5.3 from kubuntu backports
Comment 10 David Edmundson 2015-05-04 15:43:28 UTC
*** Bug 347148 has been marked as a duplicate of this bug. ***
Comment 11 H Rantala 2015-05-05 10:43:59 UTC
I have hardware monitors in a autohide panel and if the panel is hidden, plasmashell is not eating CPU but as soon the panel is show, CPU usage spikes.

NVIDIA GTX 980, nvidia driver 349.16, single monitor
Linux 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 12:00:26 CEST 2015 x86_64 GNU/Linux
Comment 12 David Edmundson 2015-05-07 22:00:58 UTC
*** Bug 347324 has been marked as a duplicate of this bug. ***
Comment 13 Steve Ramage 2015-05-23 23:20:21 UTC
I also have this problem on a Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz running Kubuntu 15.04 with an Nvidia chip. Removing the CPU Load Monitor widget drops my CPU usage of the plasmashell process from 50.7% to 20%. I also have the Hard Disk I/O Monitor displaying one graph, the Network monitor displaying 1 graph, and my CPU Load Monitor displays 13 graphs.
Comment 14 FBrown 2015-05-25 09:57:15 UTC
Tested with latest git builds from kubuntu-ci. Excessive cpu load on multiple cores still present when plotting visible on widgets.
Comment 15 bartek 2015-05-25 11:04:39 UTC
I can confirm the bug. I'm using intel i7-940  CPU. This is computer in my work, I'll check it on home machine.
Comment 16 Jannis Liapis 2015-05-26 09:32:00 UTC
confirming running kubuntu 15.04 with all the latest updates(ppa backports). plasmashell high cpu load remains even if I remove the system load widget...
Comment 17 Ancoron 2015-05-27 23:42:42 UTC
What I see with the help of a simple "top -cd 0.2 -p $(pidof plasmashell) -b" is the following:

top - 21:58:46 up 2 days, 12:17, 16 users,  load average: 2.65, 1.86, 1.40
Threads:  44 total,   2 running,  42 sleeping,   0 stopped,   0 zombie
%Cpu(s): 48.7 us, 28.2 sy,  0.0 ni, 23.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  32890516 total, 26686764 used,  6203752 free,  4159096 buffers
KiB Swap:        0 total,        0 used,        0 free. 13432668 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 9167 ancoron   20   0 5979948 753144  84040 R 98.9  2.3 201:25.38 /usr/bin/plasmashell
 9166 ancoron   20   0 5979948 753144  84040 R 79.1  2.3 264:41.56 /usr/bin/plasmashell
 9171 ancoron   20   0 5979948 753144  84040 S  0.0  2.3   0:00.10 /usr/bin/plasmashell
 9172 ancoron   20   0 5979948 753144  84040 S  0.0  2.3   2:00.43 /usr/bin/plasmashell
 9176 ancoron   20   0 5979948 753144  84040 S  0.0  2.3   0:00.08 /usr/bin/plasmashell
...

So, there are two threads playing heavy ping-pong.

The thread with PID 9166 is the main application thread and the one with PID 9167 is a thread named "QXcbEventReader", which I guess is the main XCB event dispatcher thread.

So, if both threads are so active together, my first guess was that the thread 9166 produces events that are then consumed by thread 9167.

I fired up gdb to see what the stacks are of those two threads while having the CPU, Disk I/O and network monitor widget running (although there is no difference in CPU consumption or thread usage - it's always those two threads and one thread cannot peak higher than a single CPU core):

Thread 0x7f76478697c0 (LWP 9166) "plasmashell":
#0  0x00007f764238fa7a in _int_malloc (av=av@entry=0x7f76426d2c00 <main_arena>, bytes=bytes@entry=36) at malloc.c:3786
#1  0x00007f764239250e in __GI___libc_malloc (bytes=36) at malloc.c:2895
#2  0x00007f7644b9cb7d in _xcb_in_read (c=0xe41920) at ../../src/xcb_in.c:253
#3  0x00007f7644b9cb7d in _xcb_in_read (c=c@entry=0xe41920) at ../../src/xcb_in.c:933
#4  0x00007f7644b9add7 in _xcb_conn_wait (c=c@entry=0xe41920, cond=cond@entry=0x7ffceb7f3700, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:483
#5  0x00007f7644b9c3ff in wait_for_reply (c=c@entry=0xe41920, request=1907167, e=e@entry=0x0) at ../../src/xcb_in.c:490
#6  0x00007f7644b9c512 in xcb_wait_for_reply (c=c@entry=0xe41920, request=1907167, e=e@entry=0x0) at ../../src/xcb_in.c:520
#7  0x00007f7644b9fcc5 in xcb_get_geometry_reply (c=c@entry=0xe41920, cookie=..., e=e@entry=0x0) at xproto.c:3081
#8  0x00007f763e40abb2 in dri3_get_buffers (driDrawable=<optimized out>, loaderPrivate=0xb9ab470) at ../../../../src/glx/dri3_glx.c:1069
#9  0x00007f763e40abb2 in dri3_get_buffers (driDrawable=<optimized out>, format=4099, stamp=0x60809b0, loaderPrivate=0xb9ab470, buffer_mask=1, buffers=0x7ffceb7f38d0)
    at ../../../../src/glx/dri3_glx.c:1431
#10 0x00007f7629dfa4cc in dri2_allocate_textures (statts_count=<optimized out>, statts=<optimized out>, images=<optimized out>, drawable=<optimized out>)
    at ../../../../../../src/gallium/state_trackers/dri/dri2.c:279
#11 0x00007f7629dfa4cc in dri2_allocate_textures (ctx=0x7ffceb7f3440, drawable=0x60809b0, statts=0x632f3a8, statts_count=48)
    at ../../../../../../src/gallium/state_trackers/dri/dri2.c:402
#12 0x00007f7629df769a in dri_st_framebuffer_validate (stctx=<optimized out>, stfbi=<optimized out>, statts=0x632f3a8, count=2, out=0x7ffceb7f3a50)
    at ../../../../../../src/gallium/state_trackers/dri/dri_drawable.c:83
#13 0x00007f7629d303ce in st_framebuffer_validate (stfb=0x632ef60, st=st@entry=0x2a04af0) at ../../../../src/mesa/state_tracker/st_manager.c:200
#14 0x00007f7629d31420 in st_api_make_current (stapi=<optimized out>, stctxi=0x2a04af0, stdrawi=0x60809b0, streadi=0x60809b0)
    at ../../../../src/mesa/state_tracker/st_manager.c:773
#15 0x00007f7629df7161 in dri_make_current (cPriv=<optimized out>, driDrawPriv=0x5c766f0, driReadPriv=0x5c766f0)
    at ../../../../../../src/gallium/state_trackers/dri/dri_context.c:245
#16 0x00007f7629df3ce6 in driBindContext (pcp=<optimized out>, pdp=<optimized out>, prp=<optimized out>) at ../../../../../../../src/mesa/drivers/dri/common/dri_util.c:538
#17 0x00007f763e40925a in dri3_bind_context (context=0x2951350, old=<optimized out>, draw=<optimized out>, read=<optimized out>) at ../../../../src/glx/dri3_glx.c:145
#18 0x00007f763e3dc2a7 in MakeContextCurrent (dpy=0xe40590, draw=48234548, read=48234548, gc_user=0x2951350) at ../../../../src/glx/glxcurrent.c:228
#19 0x00007f76357fcfbd in QGLXContext::makeCurrent(QPlatformSurface*) (this=0x29512e0, surface=0x326df70) at qglxintegration.cpp:476
#20 0x00007f7643054562 in QOpenGLContext::makeCurrent(QSurface*) (this=0x2951330, surface=0x3174800) at kernel/qopenglcontext.cpp:896
#21 0x00007f7647590d43 in QSGGuiThreadRenderLoop::renderWindow(QQuickWindow*) (this=0x10c50d0, window=0x31747f0) at scenegraph/qsgrenderloop.cpp:333
#22 0x00007f7647591979 in QSGGuiThreadRenderLoop::event(QEvent*) (this=0x10c50d0, e=<optimized out>) at scenegraph/qsgrenderloop.cpp:467
#23 0x00007f76435d2b2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=0xe32520, receiver=0x10c50d0, e=0x7ffceb7f4050) at kernel/qapplication.cpp:3720
#24 0x00007f76435d8000 in QApplication::notify(QObject*, QEvent*) (this=0x7ffceb7f4420, receiver=0x10c50d0, e=0x7ffceb7f4050) at kernel/qapplication.cpp:3503
#25 0x00007f7642cc8c2b in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x7ffceb7f4420, receiver=0x10c50d0, event=event@entry=0x7ffceb7f4050)
    at kernel/qcoreapplication.cpp:935
#26 0x00007f7642d20ae5 in QTimerInfoList::activateTimers() (event=0x7ffceb7f4050, receiver=<optimized out>)
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:228
#27 0x00007f7642d20ae5 in QTimerInfoList::activateTimers() (this=0xe7b630) at kernel/qtimerinfo_unix.cpp:635
#28 0x00007f7642d20f61 in timerSourceDispatch(GSource*, GSourceFunc, gpointer) (source=<optimized out>) at kernel/qeventdispatcher_glib.cpp:177
#29 0x00007f763ed39c3d in g_main_context_dispatch (context=0x7f762c0016f0) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3122
#30 0x00007f763ed39c3d in g_main_context_dispatch (context=context@entry=0x7f762c0016f0) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3737
#31 0x00007f763ed39f20 in g_main_context_iterate (context=context@entry=0x7f762c0016f0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3808
#32 0x00007f763ed39fcc in g_main_context_iteration (context=0x7f762c0016f0, may_block=1) at /build/buildd/glib2.0-2.44.1/./glib/gmain.c:3869
#33 0x00007f7642d21c57 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0xe78f90, flags=...) at kernel/qeventdispatcher_glib.cpp:418
#34 0x00007f7642cc63e2 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7ffceb7f42a0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#35 0x00007f7642cce02c in QCoreApplication::exec() () at kernel/qcoreapplication.cpp:1188
#36 0x00007f764300d31c in QGuiApplication::exec() () at kernel/qguiapplication.cpp:1510
#37 0x00007f76435ce7a5 in QApplication::exec() () at kernel/qapplication.cpp:2956
#38 0x00000000004301b3 in main(int, char**) (argc=1, argv=<optimized out>) at ../../shell/main.cpp:154

Thread 0x7f7633457700 (LWP 9167) "QXcbEventReader":
#0  0x00007f7641c98b5d in __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f7641c94b01 in __pthread_mutex_cond_lock (mutex=0xe41938) at ../nptl/pthread_mutex_lock.c:80
#2  0x00007f7641c95e30 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:259
#3  0x00007f7644b9adb9 in _xcb_conn_wait (c=c@entry=0xe41920, cond=cond@entry=0xe41960, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:415
#4  0x00007f7644b9c64f in xcb_wait_for_event (c=0xe41920) at ../../src/xcb_in.c:622
#5  0x00007f76357d5099 in QXcbEventReader::run() (this=0xe4fde0) at qxcbconnection.cpp:1105
#6  0x00007f7642a8ab0e in QThreadPrivate::start(void*) (arg=0xe4fde0) at thread/qthread_unix.cpp:337
#7  0x00007f7641c906aa in start_thread (arg=0x7f7633457700) at pthread_create.c:333
#8  0x00007f7642414eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

This is of course just a snapshot and may not even show the actual problem, but to me it looks like the OpenGL drawing waits for some synchronous message event from XCB, which might also explain the visual lags I am experiencing very heavily since the upgrade to Plasma5. Those lags increase in lag-duration and amount of occurrence with those monitoring widgets are running.
Comment 18 Ancoron 2015-05-28 00:08:17 UTC
In my case, even after removing all monitoring widgets the CPU usage first gets down to almost completely idle but then starts to consume up to 2 full cores in waves of approximately 3 seconds.

Just killed the plasmashell process and now the UI is completely smooth and responsive as I was used to under KDE SC 4.x. Of course, I don't have desktops, no panels, ... but at least I can work without annoying, demotivating and patience-stressing lags that make me work less efficient.
Comment 19 Ancoron 2015-05-28 01:07:10 UTC
Created attachment 92878 [details]
ltrace -c -f -C -L -l libdri* -l libxcb* (with CPU load monitor widget)
Comment 20 Ancoron 2015-05-28 01:07:41 UTC
Created attachment 92879 [details]
ltrace -c -f -C -L -l libdri* -l libxcb* (without any widget)
Comment 21 miku84 2015-05-30 17:29:00 UTC
same happens on Manjaro Plasma 5.3.1
Comment 22 Richard Van Den Boom 2015-05-30 18:25:09 UTC
Same here on Slackware64 using Alien Bob's Plasma 5.3.1 package.
Comment 23 Germano Massullo 2015-06-01 14:55:15 UTC
*** Bug 348411 has been marked as a duplicate of this bug. ***
Comment 24 Germano Massullo 2015-06-01 15:02:23 UTC
Confirming on Fedora 22 Kf 5.10
Comment 25 Steven Roose 2015-06-09 22:26:30 UTC
Can confirm on new Fedora 22 KDE spin. Load goes away after Network Load Widget was removed.
Comment 26 Richard Van Den Boom 2015-06-10 05:37:07 UTC
I'd like to point out that I have a very similar behaviour when uploading a file using FTP : plasmashell cpu percentage becomes very high and seems to be related to the FTP statistics provided in the notifications.
Comment 27 miku84 2015-06-10 17:42:05 UTC
(In reply to Steven Roose from comment #25)
> Can confirm on new Fedora 22 KDE spin. Load goes away after Network Load
> Widget was removed.

If ALL widget is removed, then CPU load is OK.
But even 1 CPU monitor created minimum 5% of load of plasmashell and it is increasing with more widgets added. Tried with Xrender, Opengl 2 & 3, the issue is still the same.
Comment 28 Hrvoje Senjan 2015-06-10 18:29:53 UTC
dup of bug 346134 ? or vice versa, that one has specific commit to 'blame'
Comment 30 Luca Beltrame 2015-06-12 09:52:46 UTC
Yeah, it's a dup of bug 346134.
Comment 31 viktor 2015-06-13 13:58:12 UTC
The same problem here.
While using Fedora 21 with KDE 4 I haven't experienced this problem but two weeks ago I've upgraded to the Fedora 22 with KDE Frameworks 5.10. I've noticed that even in idle mode my laptop becomes very hot in a short period of time after boot. This was a bit confusing because I've recently cleaned out my laptop and replaced thermal paste.
I've noticed (with top utility) that plasmashell process consumes about 70-120% of CPU usage even in idle mode (CPU temp is about 78-85 centigrees). Guys from #fedora-kde pointed to this bug and advised to remove all widgets from desktop. Works like a charm: CPU usage in idle by plasmashell fall to 0% and only arises to the 40-50% when switching windows etc.
Some notices:
1) clock widget consumes the most part of CPU time
2) when I'm using discrete gpu (e.g. for watching videos with vlc) my CPU overheating a bit smaller (67-70 centigrees). I'm using KWin compositing with XRender
Comment 32 Bhushan Shah 2015-06-13 14:40:03 UTC
*** Bug 349091 has been marked as a duplicate of this bug. ***
Comment 33 Andrew 2015-06-15 16:45:00 UTC
See it on Fedora 22 x64.  CPU widget consumes 1 core from 4 entirely (Intel i5-3470)

Some stats:
$ top | grep plasma
 2929 andrew    20   0 5551692 338424  88164 R 131,2  4,2 443:03.33 plasmashell
 2929 andrew    20   0 5551932 338424  88164 R 128,9  4,2 443:07.21 plasmashell
 2929 andrew    20   0 5551692 338424  88164 R 130,3  4,2 443:11.12 plasmashell
 2929 andrew    20   0 5551692 338424  88164 R 128,2  4,2 443:14.98 plasmashell
 2929 andrew    20   0 5551692 338424  88164 R 128,6  4,2 443:18.85 plasmashell



# strace -p 2929 -c & sleep 5; killall strace
[1] 13499
Process 2929 attached
Process 2929 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 54.00    0.025364           0     60503       547 futex
 27.39    0.012865           0     30197           poll
 16.84    0.007911           0     29819           recvmsg
  1.64    0.000771           0      6319           ioctl
  0.07    0.000035           0       251           writev
  0.03    0.000015           0        99        31 read
  0.01    0.000007           0        61           getcwd
  0.01    0.000003           2         2           stat
  0.00    0.000000           0        10           write
  0.00    0.000000           0         5           munmap
  0.00    0.000000           0         1           clone
------ ----------- ----------- --------- --------- ----------------
100.00    0.046971                127267       578 total



# perf record -g -p 2929 -- sleep 5
[ perf record: Woken up 10 times to write data ]
[ perf record: Captured and wrote 4.280 MB perf.data (27958 samples) ]

# perf report

Samples: 27K of event 'cycles', Event count (approx.): 19363458990
  Children      Self  Command          Shared Object                     Symbol
-   30.51%     0.01%  plasmashell      [kernel.kallsyms]                 [k] system_call_fastpath
   - system_call_fastpath
        61.11% __GI___libc_recvmsg
        28.61% __lll_unlock_wake
      + 8.61% __GI___libc_poll
      + 0.86% __GI___ioctl
        0.71% __lll_lock_wait
+   19.60%     0.15%  plasmashell      libc-2.21.so                      [.] __GI___libc_recvmsg
+   18.68%     0.09%  plasmashell      [kernel.kallsyms]                 [k] sys_recvmsg
+   18.55%     0.13%  plasmashell      [kernel.kallsyms]                 [k] __sys_recvmsg
+   18.18%     0.10%  plasmashell      [kernel.kallsyms]                 [k] ___sys_recvmsg
+   17.55%     0.13%  plasmashell      [kernel.kallsyms]                 [k] sock_recvmsg
+   16.55%     1.25%  plasmashell      [kernel.kallsyms]                 [k] unix_stream_recvmsg
+   12.44%     0.00%  plasmashell      [unknown]                         [.] 0000000000000000
+    9.76%     0.15%  plasmashell      [kernel.kallsyms]                 [k] consume_skb
+    9.70%     0.09%  plasmashell      libpthread-2.21.so                [.] __lll_unlock_wake
+    9.17%     0.56%  QXcbEventReader  libpthread-2.21.so                [.] __lll_lock_wait
+    9.08%     0.18%  plasmashell      [kernel.kallsyms]                 [k] sys_futex
+    8.88%     0.06%  plasmashell      [kernel.kallsyms]                 [k] do_futex
+    8.46%     0.61%  plasmashell      [kernel.kallsyms]                 [k] futex_wake
+    7.74%     0.07%  plasmashell      [kernel.kallsyms]                 [k] skb_release_all
+    7.43%     0.05%  QXcbEventReader  [kernel.kallsyms]                 [k] system_call_fastpath
+    7.30%     0.13%  QXcbEventReader  [kernel.kallsyms]                 [k] sys_futex
+    7.21%     0.58%  plasmashell      [kernel.kallsyms]                 [k] wake_futex
+    7.14%     0.16%  QXcbEventReader  [kernel.kallsyms]                 [k] do_futex
+    7.06%     7.03%  plasmashell      libc-2.21.so                      [.] malloc_consolidate
+    6.70%     0.61%  QXcbEventReader  [kernel.kallsyms]                 [k] futex_wait
+    6.45%     6.44%  plasmashell      libc-2.21.so                      [.] _int_malloc
+    6.35%     0.02%  plasmashell      [kernel.kallsyms]                 [k] wake_up_state
+    6.24%     1.38%  plasmashell      [kernel.kallsyms]                 [k] try_to_wake_up
+    5.03%     0.36%  QXcbEventReader  [kernel.kallsyms]                 [k] futex_wait_queue_me



A little snippet from `strace -p 2929`:

poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"f\0dU\21\0\340\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 4096
futex(0x13e4c04, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x13e4c00, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x13e4bd8, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"f\0dU\21\0\340\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 4096
futex(0x13e4c04, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x13e4c00, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x13e4bd8, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"f\0dU\21\0\340\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 4096
futex(0x13e4c04, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x13e4c00, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x13e4bd8, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}])
recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"f\0dU\21\0\340\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 4096
futex(0x13e4c04, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x13e4c00, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x13e4bd8, FUTEX_WAKE_PRIVATE, 1) = 1
Comment 34 Nic Brooke 2015-06-15 22:10:41 UTC
Another confirmation this occurs on Manjaro Plasma 5.3.1 (3,18 Kernel).  CPU useage returns to normal after all widgets removed - CPU monitor seemed to be the worst culprit.
Comment 35 3ndymion 2015-06-16 15:32:41 UTC
Here's another confirmation of this very serious problem on Fedora 22 KDE "stable" x86_64.
Comment 36 hashbang173 2015-06-25 18:03:38 UTC
I can also confirm on Fedora 22 KDE spin with the cpu load widget.
Comment 37 David Edmundson 2015-07-06 17:43:34 UTC

*** This bug has been marked as a duplicate of bug 348385 ***
Comment 38 Richard Van Den Boom 2015-07-14 08:52:43 UTC
Maybe it's not related, but I also have the same behaviour with the Media Player widget.
When no multimedia application is started, the plasmashell CPU usage stays reasonable, but as soon as I start Amarok, it saturates a core, going to 100%+ CPU.
It does not occur if no Media Player widget is added to the desktop.
Comment 39 Faisal 2015-07-25 11:56:26 UTC
Fedora 22. I have the same problem. CPU Load Monitor widget and Network Monitor widget cause the plasmashell process CPU usage to very high in top (immediately the fan makes a lot of noise). The Show Desktop widget does NOT affect plasmashell. Any dev can explain how we can debug and report  so that we can help a little.
Comment 40 Faisal 2015-07-25 12:00:47 UTC
Let me just add that this is the latest update with Fedora 22 as at 25th July 2015.
$ rpm -qa | grep kf5 
kf5-kconfig-gui-5.11.0-1.fc22.x86_64
kf5-kwallet-5.11.0-1.fc22.x86_64
kf5-solid-libs-5.11.0-1.fc22.x86_64
kf5-kwindowsystem-5.11.0-1.fc22.x86_64
kf5-attica-5.11.0-1.fc22.x86_64
kf5-frameworkintegration-libs-5.11.0-1.fc22.x86_64
kf5-kio-widgets-libs-5.11.0-3.fc22.x86_64
kf5-kded-5.11.0-1.fc22.x86_64
kf5-kdewebkit-5.11.0-1.fc22.x86_64
kf5-baloo-file-5.9.2-1.fc22.x86_64
kf5-kguiaddons-5.11.0-1.fc22.x86_64
kf5-ktextwidgets-5.11.0-1.fc22.x86_64
kf5-kitemmodels-5.11.0-1.fc22.x86_64
kf5-kpeople-5.11.0-1.fc22.x86_64
kf5-kdeclarative-5.11.0-1.fc22.x86_64
kf5-kcoreaddons-5.11.0-1.fc22.x86_64
kf5-knotifications-5.11.0-1.fc22.x86_64
kf5-kemoticons-5.11.0-1.fc22.x86_64
kf5-bluez-qt-5.11.0-2.fc22.x86_64
kf5-knewstuff-5.11.0-1.fc22.x86_64
kf5-ktexteditor-5.11.0-1.fc22.x86_64
kf5-filesystem-5.11.0-2.fc22.x86_64
kf5-kcompletion-5.11.0-1.fc22.x86_64
kf5-kiconthemes-5.11.0-1.fc22.x86_64
kf5-networkmanager-qt-5.11.0-1.fc22.x86_64
kf5-kwayland-5.3.2-1.fc22.x86_64
kf5-kglobalaccel-5.11.0-1.fc22.x86_64
kf5-kio-ntlm-5.11.0-3.fc22.x86_64
kf5-kio-core-5.11.0-3.fc22.x86_64
kf5-kinit-5.11.0-1.fc22.x86_64
kf5-baloo-5.9.2-1.fc22.x86_64
kf5-kactivities-5.11.0-1.fc22.x86_64
kf5-kross-ui-5.11.0-1.fc22.x86_64
kf5-kwidgetsaddons-5.11.0-1.fc22.x86_64
kf5-kcrash-5.11.0-1.fc22.x86_64
kf5-kwallet-libs-5.11.0-1.fc22.x86_64
kf5-kjs-5.11.0-1.fc22.x86_64
kf5-kbookmarks-5.11.0-1.fc22.x86_64
kf5-solid-5.11.0-1.fc22.x86_64
kf5-kparts-5.11.0-1.fc22.x86_64
kf5-plasma-5.11.0-1.fc22.x86_64
kf5-ki18n-5.11.0-1.fc22.x86_64
kf5-kitemviews-5.11.0-1.fc22.x86_64
kf5-kunitconversion-5.11.0-1.fc22.x86_64
kf5-modemmanager-qt-5.11.0-1.fc22.x86_64
kf5-kidletime-5.11.0-1.fc22.x86_64
kf5-kxmlgui-5.11.0-1.fc22.x86_64
kf5-kjsembed-5.11.0-1.fc22.x86_64
kf5-threadweaver-5.11.0-1.fc22.x86_64
kf5-kio-file-widgets-5.11.0-3.fc22.x86_64
kf5-kactivities-libs-5.11.0-1.fc22.x86_64
kf5-kxmlrpcclient-5.11.0-1.fc22.x86_64
kf5-kauth-5.11.0-1.fc22.x86_64
kf5-kservice-5.11.0-1.fc22.x86_64
kf5-karchive-5.11.0-1.fc22.x86_64
kf5-sonnet-ui-5.11.0-1.fc22.x86_64
kf5-kdnssd-5.11.0-1.fc22.x86_64
kf5-baloo-libs-5.9.2-1.fc22.x86_64
kf5-kdelibs4support-5.11.0-1.fc22.x86_64
kf5-krunner-5.11.0-1.fc22.x86_64
kf5-kdbusaddons-5.11.0-1.fc22.x86_64
kf5-sonnet-core-5.11.0-1.fc22.x86_64
kf5-kross-core-5.11.0-1.fc22.x86_64
kf5-kdoctools-5.11.0-1.fc22.x86_64
kf5-kdelibs4support-libs-5.11.0-1.fc22.x86_64
kf5-kconfig-core-5.11.0-1.fc22.x86_64
kf5-kconfigwidgets-5.11.0-1.fc22.x86_64
kf5-kfilemetadata-5.9.2-1.fc22.x86_64
kf5-kcmutils-5.11.0-1.fc22.x86_64
kf5-khtml-5.11.0-1.fc22.x86_64
kf5-kcodecs-5.11.0-1.fc22.x86_64
kf5-kpackage-5.11.0-1.fc22.x86_64
kf5-kdesu-5.11.0-1.fc22.x86_64
kf5-kio-core-libs-5.11.0-3.fc22.x86_64
kf5-knotifyconfig-5.11.0-1.fc22.x86_64
kf5-kjobwidgets-5.11.0-1.fc22.x86_64
kf5-kpty-5.11.0-1.fc22.x86_64
kf5-kglobalaccel-libs-5.11.0-1.fc22.x86_64
kf5-kio-widgets-5.11.0-3.fc22.x86_64
kf5-frameworkintegration-5.11.0-1.fc22.x86_64

$ rpm -qa | grep plasma
plasma-workspace-5.3.2-2.fc22.x86_64
plasma-nm-l2tp-5.3.2-1.fc22.x86_64
plasma-nm-5.3.2-1.fc22.x86_64
plasma-breeze-5.3.2-1.fc22.x86_64
kde-settings-plasma-22-11.fc22.noarch
plasma-nm-pptp-5.3.2-1.fc22.x86_64
kdeplasma-addons-5.3.2-1.fc22.x86_64
plasma-nm-vpnc-5.3.2-1.fc22.x86_64
plasma-desktop-5.3.2-3.fc22.x86_64
plasma-breeze-common-5.3.2-1.fc22.noarch
kf5-plasma-5.11.0-1.fc22.x86_64
plasma-nm-openswan-5.3.2-1.fc22.x86_64
plasma-systemsettings-5.3.2-1.fc22.x86_64
plasma-nm-openvpn-5.3.2-1.fc22.x86_64
plasma-milou-5.3.2-1.fc22.x86_64
plasma-desktop-doc-5.3.2-3.fc22.noarch
plasma-pk-updates-0.2-1.fc22.x86_64
plasma-nm-openconnect-5.3.2-1.fc22.x86_64
Comment 41 3ndymion 2015-07-25 12:44:22 UTC
I'm gonna be the bad guy here & ask the evil question.  Is there any progress on this???  Or is it still unknown???  It seems like Ancoron had it narrowed down.  I apologize that I can't help.  I don't have this knowledge.  This is a very high priority problem, & my poor laptop is burning up even with just 1 monitoring widget, so I was just wondering how things are going with this.  Thanks.
Comment 42 3ndymion 2015-08-17 16:46:03 UTC
This is working great for me now.  Problem seems fixed for some time now.  Big thanks to David Edmundson & whoever else was working on it over at bug 348385 .
Comment 43 desaparecido 2015-08-17 16:51:18 UTC
yes, testing after 2 weeks now (git version) and all works fine, tested with differs configurations (1 or 2 screens, glx or egl, etc) .  Thanks KDE's developers ;-)
Comment 44 Faisal 2015-09-01 18:38:46 UTC
Since I updated my fedora 22 about 2 weeks ago, it appears the problem is solved. Whoever you are who fixed it, thanks and you are awesome.
Comment 45 Ancoron 2015-09-22 05:34:41 UTC
For me (on a Kubuntu - KDE/Plasma packages from the backports PPA) it got a lot better, but still far from acceptable.

Just adding the three monitor widgets CPU, Disk I/O and network is enough to increase the average CPU usage from below 10% to ~30% after a few minutes. It really looks as if the effect gets worse the longer the widgets run:

$ top -bcd 1 -p 21244 | grep plasmashell
21244 ancoron   20   0 5165624 480732  92324 S   2.0  1.5  14:12.05 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165624 480732  92324 S   1.0  1.5  14:12.06 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165624 480732  92324 S   2.0  1.5  14:12.08 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165624 480732  92324 S   1.0  1.5  14:12.09 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165624 480732  92324 S   1.0  1.5  14:12.10 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165624 480732  92324 S   0.0  1.5  14:12.10 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165624 480732  92324 S   2.0  1.5  14:12.12 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166648 480732  92324 S   1.0  1.5  14:12.13 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166648 480732  92324 S   1.0  1.5  14:12.14 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165848 480996  92548 S   4.0  1.5  14:12.18 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5165708 480812  92324 S   6.0  1.5  14:12.47 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166960 480812  92324 S   5.0  1.5  14:12.52 /usr/bin/plasmashell --shut-up

...adding CPU load monitor:
21244 ancoron   20   0 5166768 480812  92324 R  33.0  1.5  14:12.85 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166852 480812  92324 R  32.0  1.5  14:13.17 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166852 480812  92324 R  41.9  1.5  14:13.59 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166852 480812  92324 S  42.9  1.5  14:14.02 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166852 480812  92324 S  42.9  1.5  14:14.45 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5166872 480812  92324 S  42.0  1.5  14:14.87 /usr/bin/plasmashell --shut-up

...adding Disk I/O monitor:
21244 ancoron   20   0 5167236 480812  92324 R  54.9  1.5  14:18.48 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167176 480812  92324 R  50.9  1.5  14:18.99 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167176 480812  92324 R  49.0  1.5  14:19.48 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167176 480812  92324 R  47.9  1.5  14:19.96 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167248 480812  92324 S  51.0  1.5  14:20.47 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167248 480812  92324 S  50.0  1.5  14:20.97 /usr/bin/plasmashell --shut-up

...adding Network monitor:
21244 ancoron   20   0 5167380 480588  92324 R  66.9  1.5  14:24.32 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167324 480588  92324 R  83.9  1.5  14:25.16 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167324 480588  92324 R  71.9  1.5  14:25.88 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167324 480588  92324 R  70.9  1.5  14:26.59 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167324 480588  92324 R  70.9  1.5  14:27.30 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5167324 480588  92324 R  72.9  1.5  14:28.03 /usr/bin/plasmashell --shut-up
Comment 46 Ancoron 2015-09-22 05:52:45 UTC
...and after some minutes:

21244 ancoron   20   0 5168920 483084  92328 R  96.9  1.5  39:28.06 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168868 483124  92328 R 102.8  1.5  39:29.09 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168856 483124  92328 R  96.9  1.5  39:30.06 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168856 483124  92328 S  92.9  1.5  39:30.99 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168856 483124  92328 R 100.9  1.5  39:32.00 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168856 483124  92328 S  96.9  1.5  39:32.97 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168920 483072  92328 S 100.8  1.5  39:33.98 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168920 483072  92328 S  95.9  1.5  39:34.94 /usr/bin/plasmashell --shut-up
21244 ancoron   20   0 5168920 483072  92328 S  98.9  1.5  39:35.93 /usr/bin/plasmashell --shut-up
Comment 47 pbhj 2015-11-06 23:59:12 UTC
(In reply to H Rantala from comment #11)
> I have hardware monitors in a autohide panel and if the panel is hidden,
> plasmashell is not eating CPU but as soon the panel is show, CPU usage
> spikes.

Just tried this, same for me no discernible CPU usage with panel hidden, 15-18% with panel visible. I'm using "system load viewer" (SLV) and "network monitor" (NM) widgets. Actually removing SLV widget reduced CPU load considerably but removing NM widget then brought it back up ... adding both again brought plasmashell --shutup up to 31% CPU (spiking) and ~200k of memory. It also caused a crash that appears related to "/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5".

Kubuntu 15.04, KDE 4.14.8; my plasma-workspace package is from Kubuntu Backports PPA.
Comment 48 Candid Dauth 2016-03-13 12:59:20 UTC
I don't think this is a duplicate of bug 348385. That bug is talking about Plasma freezing, which is not the case here.

I can still reproduce the issue with plasmashell 5.5.5 on Arch Linux.
Comment 49 starryin 2016-05-05 05:34:32 UTC
Same here, I am using Arch Linux and latest plasmashell, remove a Monitor Widget will make the plsasma-shell cpu usage 10% lower.
Comment 50 BRULE Herman 2017-08-03 14:50:57 UTC
Seam linked with my problem