| Summary: | when adding any monitor widget (CPU, MEM, NETWORK, I/O Disk) directly huge %CPU consomption with plasmashell process | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | desaparecido <luis.davila.pc> |
| Component: | general | Assignee: | Marco Martin <notmart> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | 3ndymion, ahepas1999, alpha_one_x86, ancoron.luciferis, andysem, b.gedzior, bhush94, cdauth+bugs.kde.org, christiandehne, duckientruong, ennokoester, episyron, falsagoff, firephoto, francisbrwn9, fshaked, gamaro100, germano.massullo, h-trader, hashbang173, hleroy, hrvoje.senjan, jirislaby, kde, kde, kolAflash, lbeltrame, lee295012, linux776, nic.brooke.nz, patrick.auernig, pbhj, plasma-bugs, randy, rdieter, rvdb, starryin, stevenroose, travneff, ubuntu, x, ycollette.nospam, zanetu |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
strace with network monitor widget in panel
strace without network monitor widget ltrace -c -f -C -L -l libdri* -l libxcb* (with CPU load monitor widget) ltrace -c -f -C -L -l libdri* -l libxcb* (without any widget) |
||
|
Description
desaparecido
2015-03-30 15:59:37 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. Same issue here with Kubuntu 15.04 with Plasma 5.3 beta (from kubuntu-ppa/beta). 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%. Created attachment 92357 [details]
strace with network monitor widget in panel
don't know if this is useful
Created attachment 92358 [details]
strace without network monitor widget
Looks like this happens with all widgets that are using the graph Have we got the stage to change bug status? I guess, we have sufficient amount of confirmations.. I can reproduce as well. Also reproducible here on kubuntu 15.04 with Plasma 5.3 from kubuntu backports *** Bug 347148 has been marked as a duplicate of this bug. *** 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 *** Bug 347324 has been marked as a duplicate of this bug. *** 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. Tested with latest git builds from kubuntu-ci. Excessive cpu load on multiple cores still present when plotting visible on widgets. 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. 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... 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.
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. Created attachment 92878 [details]
ltrace -c -f -C -L -l libdri* -l libxcb* (with CPU load monitor widget)
Created attachment 92879 [details]
ltrace -c -f -C -L -l libdri* -l libxcb* (without any widget)
same happens on Manjaro Plasma 5.3.1 Same here on Slackware64 using Alien Bob's Plasma 5.3.1 package. *** Bug 348411 has been marked as a duplicate of this bug. *** Confirming on Fedora 22 Kf 5.10 Can confirm on new Fedora 22 KDE spin. Load goes away after Network Load Widget was removed. 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. (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. dup of bug 346134 ? or vice versa, that one has specific commit to 'blame' FYI, bug #346134 references this commit: https://projects.kde.org/projects/frameworks/kdeclarative/repository/revisions/f4e2f0685a92428b5ae24360a7f6dfc937a62987 Yeah, it's a dup of bug 346134. 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 *** Bug 349091 has been marked as a duplicate of this bug. *** 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
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. Here's another confirmation of this very serious problem on Fedora 22 KDE "stable" x86_64. I can also confirm on Fedora 22 KDE spin with the cpu load widget. *** This bug has been marked as a duplicate of bug 348385 *** 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. 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. 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 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. 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 . 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 ;-) 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. 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 ...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 (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. 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. Same here, I am using Arch Linux and latest plasmashell, remove a Monitor Widget will make the plsasma-shell cpu usage 10% lower. Seam linked with my problem |