Created attachment 167654 [details] EDID data SUMMARY Since the upgrade to 6.0 I experienced a spin up of my CPU fans every time the screen engages. I have now had time to investigate this a bit by logging into the system via SSH and running top/htop. When I locked the screen, kwin_x11 jumped from ~5% CPU to ~70% and Xorg from ~3% to ~50%. ksmserver also moved into the top three processes. I tried again and attached gdb to the running process, interrupting it now and then. At the beginning (let's say first 1-2 minutes) the backtrace often included the KWin::Edid constructor, mostly in some memory allocation calls. Later on I only manages to interrupt it while it was in some XCB call. I can also not reproduce on a second system with relatively similar software state (both KDE Neon with the same updates installed). Two potentially related hardware differences are GPU and number of monitors. Workstation (which runs into the CPU load issue): AMD Radeon RX 550 / 550 Series, 3 monitors Laptop (which does not have the issue): Intel UHD Graphics 620, only internal monitor STEPS TO REPRODUCE 1. lock screen 2. observe CPU load via remote connection OBSERVED RESULT kwin_x11 and Xorg (though one might "drag along" the other) jump in CPU load to about 10 times their usual load EXPECTED RESULT CPU load staying atthe same as the unlocked system. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: KDE Neon 6.0.2 (?) (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION AMD Radeon RX 550 / 550 Series, 3 monitors (all 1920x1080, one is from a different vendor). Attaching output of get-edid (and parsed via parse-edid)
Can confirm I observe the same behaviour, both kwin_x11 and Xorg together using 100% CPU. This is with kwin 6.0.2-3 on manjaro. Interestingly, when I move the mouse and the screen goes from black to background image, CPU usage goes back to normal. Also interesting is that I use a LG TV as display, not a monitor, so there is no "proper" display suspend, but rather the TV shows a no-signal background picture for a while.
Hotspot profiling data pointing to where these processes are using all those cpu cycles would be extremely helpful.
(In reply to fanzhuyifan from comment #2) > Hotspot profiling data pointing to where these processes are using all > those cpu cycles would be extremely helpful. I did some profiling on kwin_x11 with debuginfod data and this is the gist of it. You can get the full trace from https://pub-32f46577ac8f4e2b84ba6635b1d55699.r2.dev/pepe.perf and load it in https://profiler.firefox.com or https://www.speedscope.app/ I have used a simple "perf report" to generate the lines below: Samples: 62K of event 'cycles:P', Event count (approx.): 23722680927 Children Self Command Shared Object Symbol - 36,84% 0,00% kwin_x11 kwin_x11 [.] 0x000055638a2d3ef4 ◆ 0x55638a2d3ef4 ▒ __libc_start_main ▒ 0x7f905a643ccf ▒ 0x55638a2cfc24 ▒ - QCoreApplication::exec() ▒ - 36,84% QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ▒ - 36,83% QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ▒ - 36,81% g_main_context_iteration ▒ - 36,62% 0x7f9059c973a6 ▒ - 36,58% 0x7f9059c38f68 ▒ - 19,21% 0x7f90559ecbd6 ▒ - 19,18% QXcbConnection::processXcbEvents(QFlags<QEventLoop::ProcessEventsFlag>) ▒ - 18,69% QXcbConnection::handleXcbEvent(xcb_generic_event_t*) ▒ - 10,83% QAbstractEventDispatcher::filterNativeEvent(QByteArray const&, void*, long long*) ▒ - 8,47% KWin::Workspace::workspaceEvent(xcb_generic_event_t*) ▒ - 6,78% KWin::Workspace::createUnmanaged(unsigned int) ▒ + 3,75% KWin::X11Window::X11Window() ▒ + 2,18% KWin::X11Window::track(unsigned int) ▒ + 0,65% operator new(unsigned long) ▒ + 1,30% KWin::Workspace::updateXStackingOrder() ▒ + 2,19% 0x7f905dbbf6d9 ▒ - 7,78% QXcbConnection::initializeScreens(bool) ▒ - 7,75% QXcbConnection::initializeScreensFromMonitor(xcb_screen_iterator_t*, int, QXcbScreen**, bool) ▒ - 6,57% QXcbConnection::updateScreen_monitor(QXcbScreen*, xcb_randr_monitor_info_t*, unsigned int) ▒ - 3,51% QXcbScreen::updateColorSpaceAndEdid() ▒ + 2,06% QEdidParser::parse(QByteArray const&) ▒ + 0,74% QXcbScreen::getEdid() const ▒ 0,69% xcb_wait_for_reply ▒ + 3,04% QXcbScreen::setMonitor(xcb_randr_monitor_info_t*, unsigned int) ▒ 0,62% xcb_wait_for_reply ▒ + 0,54% QXcbConnection::findScreenForMonitorInfo(QList<QPlatformScreen*> const&, xcb_randr_monitor_info_t*) ▒ - 17,34% 0x7f905af75723 ▒ - 17,34% QTimerInfoList::activateTimers() ▒ - 17,33% QCoreApplication::notifyInternal2(QObject*, QEvent*) ▒ - 17,33% QApplicationPrivate::notify_helper(QObject*, QEvent*) ▒ - 17,25% QObject::event(QEvent*) ▒ - 17,25% QTimer::timerEvent(QTimerEvent*) ▒ - 17,23% 0x7f905ad90ca8 ▒ - 17,20% 0x55638a2ddafc ▒ - 6,10% 0x55638a2dd69e ▒ + 6,09% KWin::Edid::Edid(void const*, unsigned int) ▒ + 4,57% 0x55638a2dccba ▒ + 3,02% 0x55638a2dc985 ▒ + 0,77% 0x55638a2dcc32 ▒ + 0,71% 0x55638a2dcfaa ▒ + 0,70% 0x55638a2dd163 ▒ + 0,67% 0x55638a2dcdff ▒
Notice that ksmserver is also using quite a bit of CPU, maybe they are sending each other events in an infinite loop? Perf for ksmserver is here: https://pub-32f46577ac8f4e2b84ba6635b1d55699.r2.dev/ksmserver.perf
Sorry, I missed there is an easier way to share this: https://profiler.firefox.com/from-url/https%3A%2F%2Fpub-32f46577ac8f4e2b84ba6635b1d55699.r2.dev%2Fpepe.perf/calltree/?globalTrackOrder=0&hiddenLocalTracksByPid=1881-2&thread=1&timelineType=category&v=10
Even better (focusing on the suspicious EDID bit). Sorry about the spam: https://share.firefox.dev/4axsSYc
(In reply to Francisco from comment #4) > Notice that ksmserver is also using quite a bit of CPU, maybe they are > sending each other events in an infinite loop? I can confirm that I also see an increased CPU use of ksmserver when the screen is locked. But maybe only twice as much as when the session is active, not 10 times as much I've seen for KWin
I've the same issue on plasma 6.0.3 with X11 and two monitors on NVIDIA.
Same. Plasma 6.0.3-1 with X11. Laptop with x1 external monitor and laptop lid closed.
Same here. plasmashell --version 6.0.3. Open suse tumbleweed with X11. I disabled auto screen lock to protect my hardware.
Unfortunately, same here. OpenSUSE Tumbleweed, Plasma 6.0.3, KWin, X11.
(In reply to leoh from comment #9) > Same. Plasma 6.0.3-1 with X11. Laptop with x1 external monitor and laptop > lid closed. Can you check if the problem also happens when the external monitor is not plugged in?
> Can you check if the problem also happens when the external monitor is not plugged in? I happens for me without the external monitor being plugged in, but only on my laptop (Intel graphics card). On my desktop (NVIDIA card) it does not seem to happen. Let me know if there's any more info I can collect.
(In reply to Kevin Krammer from comment #12) > (In reply to leoh from comment #9) > > Same. Plasma 6.0.3-1 with X11. Laptop with x1 external monitor and laptop > > lid closed. > > Can you check if the problem also happens when the external monitor is not > plugged in? Some more tests: - Happens with or without the external monitor plugged in - Happens always when locked - either blank screen when locked for a while; or lock screen (even if visible for several minutes without unlocking and not allowing screen to go black) - Interesting: if while still locked I go to console (Ctrl+Alt+Fx) it stops - no login required, just change to console.
Today's Neon package updates seem to have fixed the issue for me. It still reports the same Plasma version as before (6.0.3), but I think the Qt library was updated.
Same issue here Operating System: EndeavourOS KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 9 5900HX with Radeon Graphics Memory: 30.8 GiB of RAM Graphics Processor: AMD Radeon Graphics When screen is locked: %Cpu(s): 4,3 us, 7,5 sy, 0,0 ni, 88,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 31515,7 total, 17692,4 free, 4709,4 used, 9664,4 buff/cache MiB Swap: 2048,0 total, 2048,0 free, 0,0 used. 26806,2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12976 hc 20 0 2238200 192812 128576 R 70,0 0,6 1:26.59 kwin_x11 12770 root 20 0 1267216 170300 124572 R 40,0 0,5 1:06.25 Xorg 12885 hc 20 0 1154660 92904 76048 S 10,0 0,3 0:03.45 kwallet+ 12973 hc 20 0 1148896 93936 79272 S 10,0 0,3 0:15.75 ksmserv+ 13037 hc 20 0 4570164 385232 151264 S 10,0 1,2 0:25.73 plasmas+ %Cpu(s): 5,6 us, 6,2 sy, 0,0 ni, 88,2 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 31515,7 total, 17699,9 free, 4702,0 used, 9664,4 buff/cache MiB Swap: 2048,0 total, 2048,0 free, 0,0 used. 26813,6 avail Mem and like leoh - Interesting: if while still locked I go to console (Ctrl+Alt+Fx) it stops - no login required, just change to console. CPU usage goes back to normal. perf record kwin_x11 the first few entries are: 10.91% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009823 9.07% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000097e3 3.87% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009a81 3.51% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000097fc 3.44% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a40e 3.05% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009ae7 2.28% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000983c 2.25% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009a75 2.08% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000235de 1.96% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a433 1.50% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a441 1.47% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000e5f2 1.44% kwin_x11 libGLX_mesa.so.0.0.0 [.] 0x000000000002f356 1.40% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000095b7 1.36% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009854 1.33% kwin_x11 libGLX_mesa.so.0.0.0 [.] 0x000000000002f31e 1.21% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009858 1.03% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009883 0.83% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009872 0.75% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000235e2 0.75% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000e5a1 0.74% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009809 0.70% kwin_x11 ld-linux-x86-64.so.2 [.] 0x00000000000249e8 0.67% kwin_x11 ld-linux-x86-64.so.2 [.] 0x0000000000009839 0.61% kwin_x11 libc.so.6 [.] 0x000000000015984b 0.60% kwin_x11 ld-linux-x86-64.so.2 [.] 0x000000000000a426 0.60% kwin_x11 radeonsi_dri.so [.] 0x0000000000030c0c
Is this the same or related to: https://bugs.kde.org/show_bug.cgi?id=484606#1 ? I made comment #6 there.
(In reply to fbm224 from comment #17) > Is this the same or related to: > https://bugs.kde.org/show_bug.cgi?id=484606#1 ? I made comment #6 there. Great find, this does indeed sound like the same problem. I can also confirm the observation that the CPU load returns to normal when switching to a Linux virtual console.
Interesting observation on that other ticket which I can confirm on my system: if I restart kwin_x11 (by running kwin_x11 --replace) it does no longer show the observed CPU load behavior when locking the screen
*** Bug 484606 has been marked as a duplicate of this bug. ***
Does this still happen if you 1. kill kwin_x11 before locking the screen? 2. or disable KScreen2 in the background services settings page?
(In reply to Zamundaaa from comment #21) > Does this still happen if you > 1. kill kwin_x11 before locking the screen? When I kill kwin_x11 or call it manually with --replace then the CPU load does no longer exceed normal levels. > 2. or disable KScreen2 in the background services settings page? Will try next time I re-login
(In reply to Zamundaaa from comment #21) > Does this still happen if you Just tested without changing tty or any settings. The excessive cpu use is gone here. There must have been an update that removed the bug System: Kernel: 6.8.8-arch1-1 arch: x86_64 Desktop: KDE Plasma v: 6.0.4 Distro: EndeavourOS
(In reply to Kevin Krammer from comment #22) > (In reply to Zamundaaa from comment #21) > > Does this still happen if you > > 1. kill kwin_x11 before locking the screen? > > When I kill kwin_x11 or call it manually with --replace then the CPU load > does no longer exceed normal levels. > > > 2. or disable KScreen2 in the background services settings page? > > Will try next time I re-login Disabling KScreen2 also works to avoid the issue.
(In reply to Kevin Krammer from comment #24) > Disabling KScreen2 also works to avoid the issue. Did you disable the service, log out and log in? Because I stopped the KScreen2 service (without a new login), and that was not sufficient to fix the issue for me.
(In reply to Petr Tesařík from comment #25) > (In reply to Kevin Krammer from comment #24) > > Disabling KScreen2 also works to avoid the issue. > > Did you disable the service, log out and log in? Because I stopped the > KScreen2 service (without a new login), and that was not sufficient to fix > the issue for me. Yes, indeed. I disabled KScreen2 and logged out and back in. Locking that session did not cause the CPU load to go up (verified by being logged in via SSH from a second computer) But in that session the order of monitors was not as expected, so I am back to having KScreen2 enabled and killing kwin_x11 once after login
KScreen being stopped preventing this isn't too surprising, as it can trigger output changes and that seems to be what's using so much CPU, but > or call it manually with --replace then the CPU load does no longer exceed normal levels very much is. I don't really have an explanation for that one
(In reply to Zamundaaa from comment #27) > KScreen being stopped preventing this isn't too surprising, as it can > trigger output changes and that seems to be what's using so much CPU, but > > or call it manually with --replace then the CPU load does no longer exceed normal levels > very much is. I don't really have an explanation for that one If only "kwin_x11 --replace" had worked my guess would have been a difference in environment due to being launched from an interactive shell rather than some session manager. But since killing it and having it restarted (by systemd?) also works as a "solution" that's probably not it. Could it be the order in which different components are started? Like trying to detect a D-Bus service, but failing, and falling back to some alternative code path, while succeeding when being restarted?
(In reply to Kevin Krammer from comment #24) > Disabling KScreen2 also works to avoid the issue. Confirmed.
Same issue here with me with plasma 6.0.4 on Fedora 40. Disabling KScreen2 did the trick for me as well. Before somebody stat commenting that F40 KDE cannot run on X - actually this is not the truth. F40 KDE is capable of running "the hidden" X11 session option via manually installing package plasma-workspace-x11 and sddm-x11. These packages are part of the official repos.
I have the same issue on Manjaro, high CPU usage on locked screen after whole system upgrade that includes plasma-desktop 6.0.4-1 (In reply to Kevin Krammer from comment #24) > > When I kill kwin_x11 or call it manually with --replace then the CPU load That solution eliminated high CPU usage for me. (In reply to Kevin Krammer from comment #24) > Disabling KScreen2 also works to avoid the issue. This didn't helped.
The high CPU usage in kwin_x11 is caused by it repeatedly receiving an XCB_CONFIGURE_NOTIFY message here: https://github.com/qt/qtbase/blob/4656fabd8a6ff46f786cb48c220511ebe43ea300/src/plugins/platforms/xcb/qxcbconnection.cpp#L586 This causes a call initializeScreens() which causes EDID data to be reloaded from "/usr/share/hwdata/pnp.ids" which consumes most of the CPU cycles, but this is clearly not the root cause of the loop. I noticed that on my system, the three processes using most CPU are: kwin_x11 (81.1%), Xorg (48.5%), ksmserver (18.3%). Suspending any of these three processes (using `kill -STOP`) causes CPU usage to drop to 0% immediately. Resuming the process (using `kill -CONT`) causes the problem to return. Interestingly, there are a bunch of other processes that are using smaller amounts of CPU (1%-4%), all related to KDE: plasmashell, kscreenlocker_greet, kactivitymanagerd, kded6, org_kde_powerdevil, ... Suspending any of these does NOT fix the high CPU usage, so they are not involved in the loop. However, suspending any of the top 3 DOES stop the high CPU usage of those other processes. This suggests that the cycle is not a one-to-one communication, but a message that is being broadcast to all KDE processes (by Xorg?). Most simply ignore it (hence the low but nonzero CPU usage) while only kwin_x11 and ksmserver do something significant with it, and at least one of these processes triggers another event to be sent.
Reproduced Hardware: ROG Zephyrus G14 GA402RJ CPU: AMD Ryzen 7 6800HS GPU 1: AMD Radeon RX 6700S GPU 2: AMD Radeon 680M Memory: 10.53 GiB / 38.41 GiB (27%) Dual monitor: Display (TL140ADXP01): 2560x1600 @ 120Hz * Display (DELL U2720Q): 3840x2160 @ 60Hz DE: KDE Plasma 6.0.5 WM: KWin (X11) Qt Version: 6.6.2 In my same hardware and software environment. the only difference is: After unplugging the external monitor (DP over Type-C Cable), locking the screen does not cause 100% CPU usage. Only when the second screen (DELL U2720Q here) is connected, the locking screen causes 100% CPU usage.
After upgrade to Plasma 6.1 the behavior is still present but not as bad as before. Xorg still goes up to ~50% of one CPU, but kwin_x11 only to 30% and ksmserver only to 15%
I've been able to reliably reproduce this so far by the following: STEPS TO REPRODUCE 1. Lock the screen 2. Turn off the monitor directly via the power button (for me it's the monitor OSD with a power action) 3. Turn the monitor back on From this point forward, while the screen is locked there will be high CPU load. For me, restarting "kwin_x11" via systemd ("systemctl --user restart plasma-kwin_x11.service") temporarily fixes the issue until the screen ends up turned off again. Operating System: EndeavourOS KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.6-arch1-1 (64-bit) Graphics Platform: X11 Graphics Processor: AMD Radeon RX 6400
I can confirm this for 6.1.1. I'm using 4 monitors, one of them is sometimes turned off. Perf data looks like this: # Overhead Command Shared Object Symbol # ........ ............... ............................... ........................................................................................................................................................................... # 24.22% kwin_x11 [vdso] [.] __vdso_clock_gettime 15.66% kwin_x11 libc.so.6 [.] __sched_yield 10.43% kwin_x11 [unknown] [k] 0xffffffff81c00150 1.71% kwin_x11 libc.so.6 [.] clock_gettime@@GLIBC_2.17 1.46% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000b00d13 1.24% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000b00d00 1.02% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00000000009eea66 0.78% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00000000009eea61 0.72% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000a03904 0.71% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x0000000000b00d30 0.68% kwin_x11 libnvidia-glcore.so.555.58 [.] 0x00000000009eea59 It looks like most of the time is spent in a tight loop getting the clock and yielding. Most of the time is spent outside of kwin_x11 but filtering by dso shows where it is involved: # dso: kwin_x11 # # Total Lost Samples: 0 # # Samples: 5K of event 'cpu_atom/cycles/Pu' # Event count (approx.): 2421254389 # # Overhead Command Symbol # ........ ............... ............................................................................................................... # 0.12% kwin_x11 [.] KWin::BlendChanges::isActive 0.07% kwin_x11 [.] QtPrivate::QCallableObject<void (KWin::ZoomEffect::*)(), QtPrivate::List<>, void>::impl 0.04% kwin_x11 [.] KWin::OutputFrame::presented@plt 0.03% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0.03% kwin_x11 [.] KWin::ApplicationX11::metaObject 0.03% kwin_x11 [.] KWin::ContrastEffect::shouldContrast 0.03% kwin_x11 [.] KWin::ContrastEffect::doContrast 0.02% kwin_x11 [.] KWin::ZoomEffect::slotWindowDamaged 0.02% kwin_x11 [.] KWin::GlxLayer::doBeginFrame 0.02% kwin_x11 [.] KWin::PaintData::yTranslation@plt 0.02% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.02% kwin_x11 [.] KWin::EffectsHandler::prePaintScreen@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::isActive 0.02% kwin_x11 [.] KWin::EffectWindow::isDesktop@plt 0.02% kwin_x11 [.] KWin::ContrastEffect::drawWindow 0.02% kwin_x11 [.] KWin::GlxBackend::primaryLayer 0.02% kwin_x11 [.] KWin::SlideEffect::isActive 0.02% kwin_x11 [.] QRegion::end@plt 0.02% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.02% kwin_x11 [.] KWin::OutputLocatorEffect::isActive 0.01% vsync event mon [.] operator delete@plt 0.01% kwin_x11 [.] KWin::GlxBackend::makeCurrent 0.01% vsync event mon [.] QMetaObject::activate@plt 0.00% vsync event mon [.] QtPrivate::QCallableObject<void (KWin::SGIVideoSyncVsyncMonitorHelper::*)(), QtPrivate::List<>, void>::impl # Samples: 1M of event 'cpu_core/cycles/Pu' # Event count (approx.): 737751025988 # # Overhead Command Symbol # ........ ............... ..................................................................................................................................................................................................................................................................................... ..................................................................................................................................................................... # 0.01% kwin_x11 [.] KWin::BlurEffect::blurRegion 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::BlurEffect::prePaintWindow 0.00% kwin_x11 [.] QRegion::~QRegion@plt 0.00% kwin_x11 [.] KWin::BlurEffect::blur 0.00% kwin_x11 [.] KWin::GlxBackend::present 0.00% kwin_x11 [.] KWin::GlxBackend::doBeginFrame 0.00% kwin_x11 [.] KWin::GlxContext::makeCurrent 0.00% vsync event mon [.] KWin::SGIVideoSyncVsyncMonitorHelper::poll 0.00% vsync event mon [.] std::chrono::_V2::steady_clock::now@plt 0.00% kwin_x11 [.] KWin::GlxBackend::vblank 0.00% kwin_x11 [.] KWin::ContrastEffect::contrastRegion 0.00% kwin_x11 [.] KWin::ScreenShotEffect::isActive 0.00% kwin_x11 [.] QtPrivate::QCallableObject<void (KWin::VsyncMonitor::*)(std::chrono::duration<long, std::ratio<1l, 1000000000l> >), QtPrivate::List<std::chrono::duration<long, std::ratio<1l, 1000000000l> > >, void>::impl 0.00% kwin_x11 [.] KWin::X11Output::renderLoop 0.00% kwin_x11 [.] KWin::BlurEffect::prePaintScreen 0.00% kwin_x11 [.] QTimer::isActive@plt 0.00% kwin_x11 [.] KWin::KscreenEffect::isActive 0.00% kwin_x11 [.] QRegion::intersects@plt 0.00% kwin_x11 [.] KWin::OutputFrame::presented@plt 0.00% kwin_x11 [.] KWin::OverlayWindowX11::isVisible 0.00% kwin_x11 [.] KWin::OutputLocatorEffect::isActive 0.00% kwin_x11 [.] QRegion::QRegion@plt 0.00% kwin_x11 [.] KWin::ContrastEffect::shouldContrast 0.00% kwin_x11 [.] std::_Hashtable<KWin::EffectWindow*, std::pair<KWin::EffectWindow* const, KWin::BlurEffectData>, std::allocator<std::pair<KWin::EffectWindow* const, KWin::BlurEffectData> >, std::__detail::_Select1st, std::equal_to<KWin::EffectWindow*>, std::hash<KWin::EffectWindow*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::find 0.00% kwin_x11 [.] KWin::GlxBackend::endFrame 0.00% kwin_x11 [.] std::__detail::_Map_base<KWin::Output*, std::pair<KWin::Output* const, KWin::BlurRenderData>, std::allocator<std::pair<KWin::Output* const, KWin::BlurRenderData> >, std::__detail::_Select1st, std::equal_to<KWin::Output*>, std::hash<KWin::Output*>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true>, true>::operator[] 0.00% kwin_x11 [.] KWin::GlxPixmapTexture::onDamage Is this caused by the blur effects of plasma and konsole?
same here on plasma 6.1.2 on X11
(In reply to Kai Krakow from comment #36) > Is this caused by the blur effects of plasma and konsole? It may have been resolved, at least partially, by https://github.com/NVIDIA/open-gpu-kernel-modules/commit/1795a8bb20fe09f9939ca3e82d76791f5741e467. It mentions KDE here: https://www.nvidia.com/Download/driverResults.aspx/228410/en-us/ I'm using the 555 driver, and since the update, high CPU usage /while/ using the system has gone down.
Hi, Actual Results: kscreenlocker_greet consumes 80-90% CPU. System performance degrades. Increased power consumption and fan activity. Logs and Diagnostics: ps aux --sort=-%cpu | head -10 shows kscreenlocker_greet at the top with high CPU usage, while the screen is locked. Command: top -b -i Output: 1857 root 20 0 24.5g 278128 147164 R 80.1 0.6 119:01.30 Xorg (80.1% cpu usage) System Information: OS: Arch Linux x86_64 Host: Lenovo ThinkPad T15g Gen 1 Kernel: 6.9.9-arch1-1 Shell: fish 3.7.1 Resolution: 2560x1440 DE: Plasma 6.1.2 WM: KWin Theme: Breeze-Dark [GTK2], Breeze [GTK3] Icons: breeze-dark [GTK2/3] Terminal: yakuake CPU: Intel i9-10885H (16) @ 5.300GHz GPU: NVIDIA GeForce RTX 2070 SUPER Mobile / Max-Q (nvidia: 555.58.02) The new driver update didn't help.
I can confirm that I'm having the same problem on Fedora 40 with Plasma 6.1.3.
I don't think it's specific to kwin. I'm having the same issue on Wayland session, plasmashell and kwin_wayland both have high CPU usage.
Another confirmation, both with and without an external monitor connected. Happens both when display is visible and when it's powered off. CPU usages (from `top` over SSH): kwin_x11 ~70-75%, Xorg.bin ~50%, ksmserver ~15%, kscreenlocker_g ~10% Software: * OS: openSUSE Tumbleweed (20240807) * KDE Plasma Version: 6.1.3 (package: 6.1.3-1.1) * KDE Frameworks Version: 6.4.0 * Qt Version: 6.7.2 * Kernel Version: 6.10.3-1-default (64bit) Hardware: * Framework 16 laptop (AMD Ryzen 9 7940HS, with Radeon 780M integrated graphics) * Display: 2560x1600 (external monitor: 1920x1200, connected with DVI->HDMI through a KVM switch)
Switching to a TTY (e.g. Ctrl+Alt+F1) also fixes the CPU usage here. Interestingly (didn't see this mentioned yet) it *stays fixed* when switching back to the TTY that has the locked X/KDE session! Unlocking and re-locking the session makes it reappear.
It looks like on my system it spends *a lot* of time in QPlatformClipboard::emitChanged, full backtrace: #0 QPlatformClipboard::emitChanged (this=0x561ea0b792a0, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qplatformclipboard.cpp:87 #1 0x0000715a5cfc6b11 in SystemClipboard::setMimeData (this=0x561ea1d6fd50, data=0x561ea0f7d260, mode=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/systemclipboard.cpp:112 #2 Klipper::setClipboard (this=this@entry=0x561ea1da6ef0, item=..., mode=mode@entry=2, updateReason=updateReason@entry=Klipper::ClipboardUpdateReason::PreventEmptyClipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/klipper.cpp:688 #3 0x0000715a5cfc6fba in Klipper::slotReceivedEmptyClipboard (this=0x561ea1da6ef0, mode=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/klipper.cpp:544 #4 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #5 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #6 0x0000715a5cfdbb51 in SystemClipboard::receivedEmptyClipboard (this=0x561ea1d6fd50, _t1=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/build/klipper/libklipper_common_static_autogen/include/moc_systemclipboard.cpp:210 #7 SystemClipboard::checkClipData (this=0x561ea1d6fd50, mode=QClipboard::Clipboard) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/klipper/systemclipboard.cpp:155 #8 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #9 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #10 0x0000715a9691db01 in KSystemClipboard::changed (this=<optimized out>, _t1=<optimized out>) at /usr/src/debug/kguiaddons/build/src/KF6GuiAddons_autogen/include/moc_ksystemclipboard.cpp:142 #11 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #12 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #13 0x0000715a961a1a7f in QClipboard::changed (this=0x561ea120f5a0, _t1=<optimized out>) at /usr/src/debug/qt6-base/build/src/gui/Gui_autogen/include/moc_qclipboard.cpp:181 #14 QClipboard::emitChanged (this=0x561ea120f5a0, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qclipboard.cpp:558 #15 QPlatformClipboard::emitChanged (this=<optimized out>, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qplatformclipboard.cpp:89 #16 QPlatformClipboard::emitChanged (this=<optimized out>, mode=QClipboard::Clipboard) at /usr/src/debug/qt6-base/qtbase/src/gui/kernel/qplatformclipboard.cpp:86 #17 0x0000715a95ba16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #18 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #19 0x0000715a96f3e596 in ffi_call_unix64 () at ../src/x86/unix64.S:104 #20 0x0000715a96f3b00e in ffi_call_int (cif=cif@entry=0x7ffc45d71330, fn=<optimized out>, rvalue=<optimized out>, avalue=<optimized out>, closure=closure@entry=0x0) at ../src/x86/ffi64.c:673 #21 0x0000715a96f3dbd3 in ffi_call (cif=cif@entry=0x7ffc45d71330, fn=<optimized out>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7ffc45d71400) at ../src/x86/ffi64.c:710 #22 0x0000715a984fe860 in wl_closure_invoke (closure=closure@entry=0x715a6c003900, target=<optimized out>, target@entry=0x561ea1f94fe0, opcode=opcode@entry=2, data=<optimized out>, flags=1) at ../wayland-1.23.0/src/connection.c:1228 #23 0x0000715a984ff0d9 in dispatch_event (display=display@entry=0x561ea0a22d50, queue=queue@entry=0x561ea0a22e48) at ../wayland-1.23.0/src/wayland-client.c:1670 #24 0x0000715a984ff4f3 in dispatch_queue (display=0x561ea0a22d50, queue=0x561ea0a22e48) at ../wayland-1.23.0/src/wayland-client.c:1816 #25 wl_display_dispatch_queue_pending (display=0x561ea0a22d50, queue=0x561ea0a22e48) at ../wayland-1.23.0/src/wayland-client.c:2058 #26 0x0000715a9774c456 in QtWaylandClient::QWaylandDisplay::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at /usr/src/debug/qt6-wayland/qtwayland/src/client/qwaylanddisplay.cpp:227 #27 0x0000715a95ba194a in doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4098 #28 0x0000715a95da2d05 in QAbstractEventDispatcher::awake (this=0x561ea0b89cc0) at /usr/src/debug/qt6-base/build/src/corelib/Core_autogen/include/moc_qabstracteventdispatcher.cpp:158 #29 QEventDispatcherGlib::processEvents (this=0x561ea0b89cc0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp:401 #30 0x0000715a95b4f01e in QEventLoop::processEvents (this=0x7ffc45d717c0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:100 #31 QEventLoop::exec (this=0x7ffc45d717c0, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:182 #32 0x0000715a95b4934d in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h:74 #33 0x0000715a97af83ba in QApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:2555 #34 0x0000561e686d7d86 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/plasma-workspace/plasma-workspace-6.1.4/shell/main.cpp:188
kwin spins in: Thread 1 "kwin_wayland" hit Breakpoint 4, wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x5e5ad315a060) at ../wayland-1.23.0/src/wayland-server.c:409 409 if (!(resource_flags & WL_MAP_ENTRY_LEGACY) && (gdb) print message $39 = (const struct wl_message *) 0x70fce9d254d8 <zwp_primary_selection_source_v1_requests.lto_priv+24> (gdb) bt #0 wl_client_connection_data (fd=<optimized out>, mask=<optimized out>, data=0x5e5ad315a060) at ../wayland-1.23.0/src/wayland-server.c:409 #1 0x000070fce7c7f0a2 in wl_event_loop_dispatch (loop=0x5e5ad213aea0, timeout=<optimized out>) at ../wayland-1.23.0/src/event-loop.c:1105 #2 0x000070fce9a767fa in KWin::Display::dispatchEvents (this=<optimized out>) at /usr/src/debug/kwin/kwin-6.1.4/src/wayland/display.cpp:121 #3 0x000070fce6fa16f7 in QtPrivate::QSlotObjectBase::call (this=<optimized out>, r=<optimized out>, a=<optimized out>, this=<optimized out>, r=<optimized out>, a=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobjectdefs_impl.h:469 #4 doActivate<false> (sender=<optimized out>, signal_index=<optimized out>, argv=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:4086 #5 0x000070fce6faa850 in QSocketNotifier::activated (this=0x5e5ad2fef0b0, _t1=..., _t2=<optimized out>, _t3=...) at /usr/src/debug/qt6-base/build/src/corelib/Core_autogen/include/moc_qsocketnotifier.cpp:195 #6 QSocketNotifier::event (this=0x5e5ad2fef0b0, e=<optimized out>) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qsocketnotifier.cpp:327 #7 0x000070fce80fc51c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x5e5ad2fef0b0, e=0x7ffd58556eb0) at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:3287 #8 0x000070fce6f44d28 in QCoreApplication::notifyInternal2 (receiver=0x5e5ad2fef0b0, event=0x7ffd58556eb0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1142 #9 0x000070fce70c5b60 in QCoreApplication::sendEvent (receiver=<optimized out>, event=0x7ffd58556eb0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcoreapplication.cpp:1583 #10 QEventDispatcherUNIXPrivate::activateSocketNotifiers (this=this@entry=0x5e5ad20c26a0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp:251 #11 0x000070fce70c6676 in QEventDispatcherUNIX::processEvents (this=<optimized out>, flags=..., flags@entry=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_unix.cpp:467 #12 0x000070fce79f9693 in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at /usr/src/debug/qt6-base/qtbase/src/gui/platform/unix/qunixeventdispatcher.cpp:27 #13 0x000070fce6f4f01e in QEventLoop::processEvents (this=0x7ffd58557090, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:100 #14 QEventLoop::exec (this=0x7ffd58557090, flags=...) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp:182 #15 0x000070fce6f4934d in QCoreApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h:74 #16 0x000070fce80f83ba in QApplication::exec () at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:2555 #17 0x00005e5ac5684035 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kwin/kwin-6.1.4/src/main_wayland.cpp:639
The issue with kwin_11 occurs after connecting a second monitor: when entering sleep mode, the kwin_11 process utilizes around 90% of the CPU, and this happens constantly. If you terminate this process, it will restart as soon as the second monitor attempts to disconnect and reconnect. As a result, xOrg doesn't function properly, and Wayland is still underdeveloped, leaving us with the current situation.
This still happens on 6.2.0. Version info: * OS: openSUSE Tumbleweed (20241007) * KDE Plasma Version: 6.2.0 (package: 6.2.0-1.1) * KWin: 6.2.0-1.1 * KDE Frameworks Version: 6.6.0 * Qt Version: 6.7.3 * Kernel Version: 6.11.2-1-default (64bit) @Kevin Krammer: as this also seems to happen on Wayland (as per comments of Vasily Khoruzhick), might it be useful to adjust the title to reflect this? (as AFAIK X11 gets low(er) priority)
I experience the same behavior running Plasma 6.2.0 on Fedora 40 in a qemu VM with virtio or QXL GPU. Just opening a System monitor or Firefox makes kwin_wayland load almost all CPU cores. No such problem when running on bare metal with NVIDIA GT1030 GPU with proprietary driver v.560.36.03. Plasma 6.0 works fine both in VM and on bare metal.
I'm also still having this issue on my Laptop and Desktop. Laptop running Arch Linux + KDE Plasma 6.2.2 on Intel i5 8th gen and iGPU without external monitor. Desktop running Arch Linux + KDE Plasma 6.2.2 on AMD Ryzen 5 3600 + AMD RX 5700. Killing kwin_x11 and restarting it solves the issue temporarily.
Same CPU load issue when screen is locked. Debian testing (Plasma 6.2.3, framework 6.6.0, Qt 6.7.2, kernel 6.11.10, X11, AMD 7840U with iGPU). Disabling compositing (W/A found here: https://unix.stackexchange.com/questions/782688/kde-lockscreen-kscreenlocker-greet-high-cpu-usage) helped in my case, the CPU load is then negligible and no crazy fan noise. But I'm not sure it solves the root issue, it may just make it less CPU expensive. The following things seem to have an impact: 1) external screen on or off; 2) screen power saving when locked; 3) compositor on or off. At first, I had two screens with compositor on. Then systematically, when locking the screen the following happens: - power saving flip-flop: the screens go into power saving (turned off), then quickly turn back on. This cycle repeats; - the CPU load increases, the fan gets loud. Turning off the external screen doesn't help in this case, same issue with just the internal one. Turning the compositor off as recommended in the previous link helps with the CPU load. But the power state flip-flop still happens. Then turning the external screen fixes the flip-flop too. With both only laptop screen and compositor off, the internal screen goes into low power and remains there. No load, no fan noise.
One more test: in my case switching to Wayland makes both issues disappear. No more high CPU load, and the screen remain in low-power (no constant flip-flopping). For others it was not the case, so there may be different issues with the same result, high CPU load with screen(s) locked.
For me the issue went away eventually, possibly by upgrading some packages. For reference, I'm now on Plasma 6.2.4, Qt 6.8.0 and Xorg 21.1.14. It might be worth confirming if other people are still having the issue on those versions, or only on lower version numbers (in which case upgrading might fix the problem).
Problem still persists for me on 6.2.4/Neon 24.04/X11.
It has been a couple of weeks since I don't find this issue anymore. Latest Arch packages, 3 monitors (2 connected to iGPU 9700x and 1 to 4060ti), X11
The issue is still here on my laptop with Arch Linux and the latest packages, right now, this is: Operating System: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 Kernel Version: 6.12.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 16 × 12th Gen Intel® Core™ i7-1270P Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Iris® Xe Graphics Manufacturer: LENOVO Xorg: 21.1.14
Still an issue here as well: * OS: openSUSE Tumbleweed (20241215) * KDE Plasma Version: 6.2.4 (package: 6.2.4-1.2) * KWin: 6.2.4-2.1 * KDE Frameworks Version: 6.9.0 * Qt Version: 6.8.1 * X11: 21.1.14-3.1 * Kernel Version: 6.11.8-1.1 (64bit)