SUMMARY I just updated to Plasma 5.26 and immediatly noticed that plasmashell is constantly using up 70-90% CPU in idle without anything else happening. It only happens when in a Wayland session, X session CPU usage is fine. Tested on both a Thinkpad E14 Gen 2 with AMD IGPU and on desktop with an AMD RX 6600XT discrete GPU. STEPS TO REPRODUCE 1. Start a plasma-wayland session 2. Observe CPU usage of plasmashell with top or htop OBSERVED RESULT High CPU Usage EXPECTED RESULT low to no CPU usage SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.26 (available in About System) KDE Plasma Version: 5.26 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6
Could you run perf top -K to see what's hogging the CPU?
Here's the output: 4.60% [vdso] [.] __vdso_clock_gettime 2.40% perf [.] hist_entry__sort 2.23% libwayland-client.so.0.21.0 [.] wl_proxy_marshal_array_flags 2.05% perf [.] rb_next 1.80% perf [.] hpp__sort_overhead 1.70% libc.so.6 [.] __libc_calloc 1.65% libglib-2.0.so.0.7400.0 [.] g_main_context_check 1.21% libQt5Core.so.5.15.6 [.] QCoreApplicationPrivate::sendThroughApplicationEvent 1.09% libc.so.6 [.] cfree 1.05% perf [.] perf_hpp__is_dynamic_entry 0.79% libc.so.6 [.] pthread_mutex_lock 0.78% libQt5Core.so.5.15.6 [.] QObject::~QObject 0.76% perf [.] hists__calc_col_len.part.0 0.73% libQt5Core.so.5.15.6 [.] QEventDispatcherUNIX::processEvents 0.63% libc.so.6 [.] malloc 0.59% libglib-2.0.so.0.7400.0 [.] g_main_context_prepare 0.59% libc.so.6 [.] 0x00000000001541d4 0.55% perf [.] output_resort 0.54% libc.so.6 [.] pthread_cond_signal 0.52% libQt5Core.so.5.15.6 [.] QCoreApplication::notifyInternal2 0.51% libQt5Widgets.so.5.15.6 [.] QApplication::notify 0.51% libwayland-client.so.0.21.0 [.] wl_display_read_events 0.50% perf [.] evsel__parse_sample 0.48% libQt5Core.so.5.15.6 [.] QInternal::activateCallbacks 0.45% libglib-2.0.so.0.7400.0 [.] g_mutex_lock 0.43% perf [.] __rb_hierarchy_next
perf top -K -p $(pidof plasmashell) whats the output when plasmashell is taking up CPU?
(In reply to Fushan Wen from comment #3) > perf top -K -p $(pidof plasmashell) > > whats the output when plasmashell is taking up CPU? Command doesn't work, I get "Failed to mmap with 22 (Invalid argument)".
On my Arch Linux plasmashell uses 30% and kwin_wayland uses 20% of cpu all the time. This does not occur on X11. And weirdly I can't reproduce using Wayland session with another user account.
Could you test if the issue is gone after fully updating your Arch system now (specifically, kimageformats-5.99.0-2)? If so, it was probably the same as Bug 460085 and is now fixed. If the issue persists then Bug 460085 probably isn't related.
(In reply to Firlaev-Hans from comment #6) > Could you test if the issue is gone after fully updating your Arch system > now (specifically, kimageformats-5.99.0-2)? > If so, it was probably the same as Bug 460085 and is now fixed. > > If the issue persists then Bug 460085 probably isn't related. Sadly no, load is still high.
I seem to be having the same issue (about 70% cpu usage of plasmashell and 30% kwin when running on wayland). I noticed this bug after updating to 5.26 from the 5.26 beta (5.25.90), so this bug seems to be introduced after the beta release. I am also on arch. After downgrading only kwin to 5.25.90 (plasma-workspace is still on 5.26) the bug didn't happen anymore, so it seems like this is a kwin bug not a plasmashell bug. After doing a git bisect on kwin it seems like the cherry pick commit https://invent.kde.org/plasma/kwin/-/commit/abf40c4a94c2c19dab4324c5879ca01ad048ffdc introduced this bug.
Can confirm, a downgrade to kwin 2.5.90 indeed fixes it.
I can confirm this happens after upgrading to Plasma 5.26 on Arch. Currently plasmashell is using around 20% CPU and kwin_wayland about 12%. Running the perf commands unfortunately gives me the same error as Cihan reported. I'll try to investigate that error and I'll post again if I make any progress. Marking as confirmed since it seems to be affecting more than 1 person. Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch2-1 (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz Memory: 3.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 Manufacturer: Acer Product Name: Aspire F5-573 System Version: V1.27
Unfortunately, I couldn't find a way to get perf data from a specific process, but this is the output of perf top -K: Samples: 184K of event 'cycles', 4000 Hz, Event count (approx.): 22948410615 lost: 0/0 drop: 0/0 Overhead Shared Object Symbol 2,13% libQt5Core.so.5.15.6 [.] QCoreApplicationPrivate::sendThroughApplicationEventFilters 1,65% libc.so.6 [.] malloc 1,56% libc.so.6 [.] cfree 1,46% libc.so.6 [.] __libc_calloc 1,40% libc.so.6 [.] pthread_mutex_lock 1,10% [vdso] [.] __vdso_clock_gettime 0,97% libQt5Core.so.5.15.6 [.] QMetaObject::activate 0,85% libwayland-client.so.0.21.0 [.] wl_proxy_marshal_array_flags 0,78% [vdso] [.] 0x0000000000000695 0,74% libQt5Core.so.5.15.6 [.] QMutex::lock 0,71% libwayland-client.so.0.21.0 [.] wl_display_read_events 0,65% libQt5Core.so.5.15.6 [.] QEventDispatcherUNIX::processEvents 0,61% libc.so.6 [.] clock_gettime 0,61% libQt5Widgets.so.5.15.6 [.] QApplication::notify 0,57% libQt5Core.so.5.15.6 [.] QMutex::unlock 0,57% libffi.so.8.1.1 [.] 0x0000000000002318 0,55% libglib-2.0.so.0.7400.0 [.] g_mutex_lock 0,54% libQt5Core.so.5.15.6 [.] QObjectPrivate::maybeSignalConnected 0,54% libglib-2.0.so.0.7400.0 [.] g_main_context_check 0,49% libQt5Core.so.5.15.6 [.] QObject::~QObject 0,48% libglib-2.0.so.0.7400.0 [.] g_mutex_unlock 0,46% libQt5Core.so.5.15.6 [.] QCoreApplicationPrivate::sendPostedEvents 0,45% libglib-2.0.so.0.7400.0 [.] g_source_ref 0,43% libc.so.6 [.] 0x0000000000153840 0,43% libQt5Widgets.so.5.15.6 [.] QApplicationPrivate::notify_helper 0,41% libc.so.6 [.] pthread_getspecific 0,41% libQt5Core.so.5.15.6 [.] QCoreApplication::notifyInternal2 0,41% libc.so.6 [.] 0x000000000008b472 0,40% perf [.] hpp__sort_overhead 0,39% libc.so.6 [.] pthread_cond_wait 0,38% libc.so.6 [.] pthread_mutex_unlock 0,38% libglib-2.0.so.0.7400.0 [.] g_main_context_prepare 0,38% perf [.] rb_next 0,38% libc.so.6 [.] __poll 0,37% ld-linux-x86-64.so.2 [.] __tls_get_addr libQt5Core.so.5.15.6 [.] QCoreApplicationPrivate::sendThroughApplicationEventFilters is always on top. If I "zoom" into it using the perf tool I get: Samples: 70K of event 'cycles', 4000 Hz, Event count (approx.): 10027589808, DSO: libQt5Core.so.5.15.6 lost: 0/0 drop: 0/0 Overhead Symbol 1,59% [.] QCoreApplicationPrivate::sendThroughApplicationEventFilters 0,82% [.] QMetaObject::activate 0,67% [.] QObjectPrivate::maybeSignalConnected 0,61% [.] 0x000000000029452b 0,53% [.] 0x0000000000346f54 0,52% [.] QMutex::lock 0,48% [.] 0x00000000002bd2f4 0,43% [.] QEventDispatcherUNIX::processEvents 0,37% [.] QObject::~QObject 0,36% [.] QCoreApplication::notifyInternal2 0,35% [.] QMutex::unlock 0,34% [.] 0x00000000002bd2d8 0,32% [.] 0x00000000002bd360 0,30% [.] QCoreApplicationPrivate::sendPostedEvents 0,30% [.] 0x00000000002bd385 0,29% [.] QHashData::nextNode 0,27% [.] QArrayData::allocate 0,25% [.] QObject::event 0,21% [.] QIODevice::read 0,21% [.] 0x00000000002bd096 0,20% [.] 0x00000000002b83ac 0,20% [.] 0x00000000002bd104 0,19% [.] qCalculateBlockSize 0,19% [.] QTimerInfoList::timerWait 0,18% [.] QEventDispatcherUNIXPrivate::activateSocketNotifiers 0,18% [.] QVariant::~QVariant 0,16% [.] QThread::currentThreadId 0,16% [.] QObjectPrivate::~QObjectPrivate 0,15% [.] QEventDispatcherUNIXPrivate::markPendingSocketNotifiers 0,15% [.] QWaitCondition::wakeOne 0,15% [.] QCoreApplicationPrivate::sendThroughObjectEventFilters 0,15% [.] QListData::append 0,15% [.] QEventLoop::processEvents 0,15% [.] QTimerInfoList::activateTimers 0,14% [.] QInternal::activateCallbacks
Sönke Holz is right. Re-enabling the option to paste with a middle click on the general behavior KCM makes the CPU usage go back to normal. Disabling it makes the CPU usage go up.
I believe that I am experiencing this same bug. After rebooting the system and logging in, the computer sat idle on the desktop for 30 minutes. The CPU fan had been running non-stop since login. After sitting idle for 30 minutes, I opened the System Monitor and found that my CPU was running 30% - 40%. Plasmashell was running 20% - 25% and kwin_wayland was running 10% - 15% constantly. This is a brand-new fresh installation of Arch Linux as of yesterday (Saturday, October 15, 2022). Operating System: Arch Linux KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch2-1 (64-bit) Graphics Platform: Wayland Processors: 4 × 11th Gen Intel® Core™ i3-1115G4 @ 3.00GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: Intel(R) Client Systems Product Name: NUC11TNKi3 System Version: M11929-403
Can also confirm, CPU usage goes up when "paste selected text" is unticked. Ticking it makes the problem go away instantly.
Solution: Enable the Middle Click: [_] Paste selected text option on the System Settings -> Workspace Behavior -> General Behavior KCM. System Settings -> Workspace Behavior -> General Behavior Middle Click: [X] Paste selected text I can confirm as well that this solution works. After rebooting and logging in again, just sitting idle at the desktop, everything is back to normal. In the System Monitor, plasmashell shows only about 1%, and kwin_wayland isn't registering any CPU usage.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/74
(In reply to Bug Janitor Service from comment #16) > A possibly relevant merge request was started @ > https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/74 That's the final bugfix, a patched kguiaddons completely solves it :)
Git commit a30c1fd20870c425e586cec3d46d7eb944509b89 by David Edmundson. Committed on 17/10/2022 at 20:54. Pushed by davidedmundson into branch 'master'. systemclipboard: Don't signals data source cancellation Right now we emit "selectionChanged" when either: - we get an external new selection - our own selection gets cancelled Semantically that's correct, if our own selection gets cancelled there's no data in the clipboard, globally it's changed. Pragmatically, we don't need to know about the latter event. It's not useful information for userspace code - and worst means we process events twice if clipboard is transferred from klipper to a client. This fixes a major issue with klipper when a user disables middle click paste. The compositor sends a cancel event on new clipboards, klipper detects the clipboard is empty and populates it. M +0 -2 src/systemclipboard/waylandclipboard.cpp https://invent.kde.org/frameworks/kguiaddons/commit/a30c1fd20870c425e586cec3d46d7eb944509b89