Created attachment 101421 [details] perf record -e cpu-clock -p `pidof plasmashell` -o perf2.data # switch between desktops a couple of times and ^C For many months I have experienced performance issues: - Obvious animation lags, e.g. switching between desktops, or hiding/restoring windows - Keyboard input handling seems to stutter, e.g. typing in the terminal or browser is not smooth: If I hold a key pressed, instead of showing a steady stream of characters, the input seems to stutter. - Videos are shown with multiple framedrops every few seconds, e.g. in VLC or in YouTube/Facebook videos in Chromium. Although I don't know how to reproduce the issue, it is not a question of whether the performance issues occur, but when (maybe after a few hours of use?). The issue is really caused by plasmashell, if I stop plasmashell the performance issues disappear, when I resume plasmashell the issues return: $ pkill -SIGSTOP plasmashell # perf issues gone, and plasmashell is obviously unusable (frozen/stopped). $ pkill -SIGCONT plasmashell # perf issues back The work-around to restart plasmashell, but doing so reorders the task items so it is not free of side effects. $ kquitapp5 plasmashell && kstart5 plasmashell --- ADDITIONAL INFORMATION After about a week of usage (with a few suspend/resume in between, some web browsing and using the terminal), I saw the issue again. I used "ps -o pcpu -C plasmashell" to get the CPU usage and saw the reported CPU drop from 28.8 to 2.2 after restarting plasmashell. After taking two more measures after an hour and another few hours the numbers slowly climbed to 2.5, then 3.8%. Then I recorded the CPU usage using perf while switching between desktops (5 times). The result is shown below (and attached). It seems that something in plasmashell is holding locks excessively often. And also the time spent by qstrcmp is a bit suspicious. $ perf record -e cpu-clock -p `pidof plasmashell` -o perf2.data $ perf report -i perf2.data Samples: 19K of event 'cpu-clock:u', Event count (approx.): 4926500000 Overhead Command Shared Object Symbol 16.53% plasmashell libpthread-2.24.so [.] __lll_lock_elision 7.91% plasmashell libpthread-2.24.so [.] __lll_unlock_elision 7.74% plasmashell libQt5Core.so.5.7.0 [.] qstrcmp 5.80% QXcbEventReader libpthread-2.24.so [.] __lll_lock_elision 5.31% QXcbEventReader libc-2.24.so [.] malloc 3.96% plasmashell libc-2.24.so [.] _int_free 3.32% plasmashell libQt5Core.so.5.7.0 [.] QAbstractEventDispatcher::filterNativeEvent 3.27% plasmashell libc-2.24.so [.] malloc 2.77% QXcbEventReader libc-2.24.so [.] _int_malloc 2.53% plasmashell libc-2.24.so [.] malloc_consolidate 2.51% QXcbEventReader libc-2.24.so [.] __memmove_avx_unaligned_erms 2.34% plasmashell libc-2.24.so [.] _int_malloc 1.75% plasmashell libQt5Core.so.5.7.0 [.] QMutex::lock 1.38% plasmashell libQt5Core.so.5.7.0 [.] QMutex::unlock 1.33% plasmashell libQt5XcbQpa.so.5.7.0 [.] QXcbConnection::processXcbEvents 1.32% QXcbEventReader libpthread-2.24.so [.] __lll_unlock_elision 1.26% QXcbEventReader libpthread-2.24.so [.] pthread_cond_signal@@GLIBC_2.3.2
Created attachment 101422 [details] perf record -e cpu-clock -p `pidof plasmashell` # After restarting plasmashell For comparison, this is what I get right when I switch desktops (5x) after restarting plasmashell. The excessive time spent in locks is absent in this recording. Usage: $ perf report -i perf.data
I'm a bit lost, the report is about plasmashell taking up lots of CPU when running in the background. Then there's a perf trace of you actively using Plasma switching desktops. For the problem reported, surely we want a perf trace of it being left alone? But in any case, we've seen this reported before where CPU is high because we're processing a tonne of X events coming in at many hundreds of times a second. Which is what your'e seeing. Whilst we could optimise our X event filtering the real question is "why is that happening" - and that means debugging both plasma and xorg simultaneously... There's some stuff on this in the generally massive bug 356479. Though that's become just a dumping ground for anyone blabbering about any slowness.
One of the issues is that animations is slow. Switching desktops includes an animation (the cube animation in my case), hence I used that as a test. I don't know whether the observation in the perf recording is related to my issue (I think it does, but I would not be surprised if it is not). My actual CPU usage is far from 100%, so this is probably different from bug 356479.
Hello, I can confirm this bug. I'm using Manjaro KDE 16.10 and after a while plasmashell takes about 15-20% CPU which result in the performance issues described above. I don't have a lot of fancy animation configured and my most used apps are : - firefox - atom-editor - konsole I have some extra plasmoid configured : - redshift - system load - thermal monitor - network monitoring This bug is really difficult to reproduce and I don't know how to analyse it. Can anyone give me some commands to execute so that I can report more technical informations here ? Regards, Smith
I'm facing the same issue and it's driving me nuts. I leave my system open and logged in when I finish my day. The next day, with a probability of close to 100%, plasma becomes almost unusable. It slows down significantly and consumes what appear to be a core. While it's relatively easy to reproduce (just wait a couple of hours), I really don't know the source of the problem. I'm using (up-to-date) ArchLinux x86_64, KDE Frameworks 5.28.0, Qt 5.7 (xcb), intel graphics. I have many windows opened: -Atom editor - Chromium - git gui & gitk - a couple of konsole terminals (with tmux in them with a dozen tmux windows) - Thunderbird - Minimized to tray (unused) I have "KDE Remote Desktop Client" and "simplescreenrecorder" If I call strace on plasmashell I get a ton of: futex(0x8c5e00, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x8c5e00, FUTEX_WAIT_PRIVATE, 3, NULL) = 0 futex(0x8c5e00, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x8c5e00, FUTEX_WAIT_PRIVATE, 3, NULL) = 0 and futex(0x8c5e00, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x8c5e00, FUTEX_WAIT_PRIVATE, 3, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x8c5e00, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x8c5e00, FUTEX_WAIT_PRIVATE, 3, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x8c5e00, FUTEX_WAKE_PRIVATE, 1) = 0 I also get many things related to `DRM_IOCTL_I915_GEM_*` Running perf for 10 seconds (and not interacting with the machine): $ perf record -e cpu-clock -p `pidof plasmashell` -o perf2.data $ perf report -i perf2.data Samples: 15K of event 'cpu-clock:u', Event count (approx.): 3958500000 Overhead Command Shared Object Symbol 18.26% plasmashell libpthread-2.24.so [.] __lll_lock_elision 8.97% QXcbEventReader libc-2.24.so [.] malloc 7.15% plasmashell libQt5Core.so.5.7.0 [.] qstrcmp 5.85% plasmashell libc-2.24.so [.] _int_free 5.62% QXcbEventReader libpthread-2.24.so [.] __lll_lock_elision 5.23% QXcbEventReader libc-2.24.so [.] _int_malloc 4.88% plasmashell libpthread-2.24.so [.] __lll_unlock_elision 3.03% plasmashell libQt5Core.so.5.7.0 [.] QMutex::lock 2.67% plasmashell libQt5XcbQpa.so.5.7.0 [.] QXcbConnection::processXcbEvents 2.67% plasmashell libQt5Core.so.5.7.0 [.] QAbstractEventDispatcher::filterNativeEvent 2.34% QXcbEventReader libc-2.24.so [.] __memmove_avx_unaligned_erms 2.23% QXcbEventReader libpthread-2.24.so [.] pthread_cond_signal@@GLIBC_2.3.2 1.62% plasmashell libQt5Core.so.5.7.0 [.] QMutex::unlock 1.54% plasmashell libpthread-2.24.so [.] pthread_mutex_lock 1.31% QXcbEventReader libpthread-2.24.so [.] __lll_unlock_elision 1.09% plasmashell libQt5Core.so.5.7.0 [.] QCoreApplicationPrivate::sendThroughApplicationEventFilters 0.88% plasmashell libQt5XcbQpa.so.5.7.0 [.] QXcbConnection::handleXcbEvent 0.73% QXcbEventReader libQt5Core.so.5.7.0 [.] QMutex::lock 0.63% QXcbEventReader libc-2.24.so [.] _int_free 0.54% plasmashell libc-2.24.so [.] pthread_mutex_lock 0.49% plasmashell libQt5Core.so.5.7.0 [.] QObject::event 0.48% plasmashell libX11.so.6.3.0 [.] XESetWireToEvent 0.45% QXcbEventReader libQt5Core.so.5.7.0 [.] QMetaObject::activate 0.45% plasmashell ld-2.24.so [.] _dl_update_slotinfo 0.44% QXcbEventReader libQt5Core.so.5.7.0 [.] QMutex::unlock 0.44% plasmashell libc-2.24.so [.] free 0.41% QXcbEventReader libpthread-2.24.so [.] pthread_mutex_lock [...] Using modesetting driver. From /var/log/Xorg.0.log: [...] [115563.964] (EE) Failed to load module "intel" (module does not exist, 0) [115563.964] (II) LoadModule: "modesetting" [115563.964] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [115563.965] (II) Module modesetting: vendor="X.Org Foundation" [115563.965] compiled for 1.18.4, module version = 1.18.4 [115563.965] Module class: X.Org Video Driver [115563.965] ABI class: X.Org Video Driver, version 20.0 [...] Note sure what other information I can provide.
I think Atom Editor is making this bug appear more quickly but I may be wrong. I'm using i915 with the following xorg.conf : Section "Device" Identifier "Device0" Driver "intel" BusID "PCI:0:2:0" Option "AccelMethod" "sna" Option "DRI3" "1" Option "DRI" "3" EndSection
Interesting... I don't use any Xorg config at all. I might try stopping Atom to see if I can reproduce.
I left my session opened over the weekend _without_ Atom opened. The problem still presents itself.
I've updated Plasma (5.29.0-1 -> 5.30.0-1), KDE Applications (16.12.0-1 -> 16.12.1-1) and qt5-base (5.7.1-1 -> 5.7.1-2) 13 days ago (full Arch Linux system update with pacman -Syu) and haven't logged out yet. I'm not having the problem anymore, which is surprising because a single day could trigger the issue before.
I have the same issues with kde under neon (up2date), and I had it in ubuntu before, on two laptops, one lenovo x1 and one dell latitude. By now I am very sure by now, the issue is triggered by suspending and waking the system. As it is not immediately showing up every time, one might suspect other causes first, especially since usually it comes up after leaving the machine on for long times (where one might forget the suspends inbetween) I did patch the BusyIndicator entry in NotificationIcon.qml in the past on one of those laptops, as it is one of the circulating proposed fixes for plasmashell cpu usage, and one of my laptops does neither use dual screen nor any animated plasmoids. The only animated thing is the icon of sparkleshare for me. turning it off did not help however. suspending and resuming almost always triggers the cpu spike. it totally blocks at least one core for me, resulting in plasmashell eating up to 128% cpu.
I followed this bug because I was having exact the same symptoms, I could track the issue to some applications both are using java: - Pycharm community edition - Soap UI Both apps work normally when launched, but if they are left overnight, system becomes unusable. I would say that's the problem appears when the memory available is low (I've 8G and usually around 6G used). The exact same issue happens when I open chromium (huge memory consumer) o when I have more than two firefox instances running (with two it's fine).
Joan, since you mention this, are you sure it is only plasmashell in your case that is slowing the system? One of my two machines I work with and mentioned, having this plasmashell bug, had 4GB RAM and showed symptoms of kswapd0 starting to completely freak out even if there was still RAM and swap space left, with short spikes in top - but it was not swapping. I fixed that issue with upgrading to 8GB, and assume its something that came up in the kernel in 2018 (for me as neon user, its ubuntu), as the issue started after an upgrade. Since both things could happen at the same time, I also first blamed the plasmashell issue. However the other laptop has 16GB RAM; far from being filled. The issue of plasmashell eating CPU happens even then. Even further, when plasmashell eats CPU, as it's an 8th gen i7, I actually only realize it through Cpu meters.
Hello and thank you again for the bug report! Unfortunately we were not able to address it yet, nor even manage to reproduce the issue ourselves. Can we ask you to please check if this issue is still happening with Plasma 5.27? If it is, please change the status to REPORTED. Thanks a lot!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!