| Summary: | High CPU usage on kwin_x11/Xorg when screen is off | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Bráulio Barros de Oliveira <brauliobo> |
| Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | aenigma1372, archiemeng, fanzhuyifan, fbm224, i, KDE, krammer, michael, tagwerk19, xaver.hugl |
| Priority: | NOR | ||
| Version: | 6.0.2 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=484323 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Bráulio Barros de Oliveira
2024-03-27 14:55:40 UTC
It would be greatly appreciated if you could provide hotspot profiling data pointing to where these processes are using all those cpu cycles. (In reply to fanzhuyifan from comment #1) > It would be greatly appreciated if you could provide hotspot profiling data > pointing to where these processes are using all those cpu cycles. sure, please provide me some instructions on how to do it, never did it before (In reply to Bráulio Barros de Oliveira from comment #2) > (In reply to fanzhuyifan from comment #1) > > It would be greatly appreciated if you could provide hotspot profiling data > > pointing to where these processes are using all those cpu cycles. > > sure, please provide me some instructions on how to do it, never did it > before One way would be to ssh into the machine with screen turned off and do perf record -p <pid> -g Then after getting enough samples, press Ctrl-C and run perf report You could also check out https://github.com/KDAB/hotspot?tab=readme-ov-file#record-data Thanks! here it is: https://we.tl/t-Ngcv3Chl3I please let me know if it is enough. had to upload there to overcome the 4mb attachment limit here Same here on Arch Linux with kwin_x11 6.0.3.1-2. However, unlike bug report 484323, it doesn't require external monitors. It just need at least one window at maximized status or multiple windows overlapped (have parts one over another). And this will only happen at the first run of kwin after sddm (not yet tested on other DM). If kwin was restart by systemd or manual command "kwin_x11 --replace" which will not restart sddm, it will not have high CPU usage after lock screen. Hi, I think I might have the same bug, I made a post about that: https://discuss.kde.org/t/kscreenlocker-greet-high-cpu-use/14059/1 ''' for i in $(seq 1 6); do sleep 10; top -b -n 1 | tail -n+6 | head ; done ``` PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2107 neo 20 0 6442812 624076 197856 S 53.33 3.843 15:18.56 plasmashell 1452 root 20 0 1205924 117996 68748 S 6.667 0.727 2:28.62 Xorg.bin 1980 neo 20 0 4161400 244828 133384 S 6.667 1.508 2:37.91 kwin_x11 1 root 20 0 23148 14596 10780 S 0.000 0.090 0:02.18 systemd 2 root 20 0 0 0 0 S 0.000 0.000 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0.000 0.000 0:00.00 pool_workqueue_release 4 root 0 -20 0 0 0 I 0.000 0.000 0:00.00 kworker/R-rcu_g 5 root 0 -20 0 0 0 I 0.000 0.000 0:00.00 kworker/R-rcu_p PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1452 root 20 0 1224204 126060 76812 R 62.50 0.776 2:33.94 Xorg.bin 1980 neo 20 0 4161408 244340 133384 R 62.50 1.505 2:43.91 kwin_x11 2107 neo 20 0 6442812 624076 197856 S 62.50 3.843 15:24.80 plasmashell 1972 neo 20 0 1097276 77936 63400 S 18.75 0.480 0:12.51 ksmserver 2397 neo 20 0 1541756 288844 67268 S 12.50 1.779 0:03.50 DiscoverNotifie 2777 neo 20 0 1096984 72676 59360 S 12.50 0.448 0:01.76 akonadi_contact 12349 neo 20 0 2993848 251476 158452 S 12.50 1.549 0:01.25 kscreenlocker_g 679 root 20 0 194344 71424 70272 S 6.250 0.440 0:03.08 systemd-journal PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1980 neo 20 0 4071252 244260 133384 R 66.67 1.504 2:50.76 kwin_x11 1452 root 20 0 1213324 126060 76812 S 60.00 0.776 2:40.03 Xorg.bin 2107 neo 20 0 6442812 624076 197856 S 60.00 3.843 15:31.14 plasmashell 1972 neo 20 0 1097276 77936 63400 S 26.67 0.480 0:14.45 ksmserver 2777 neo 20 0 1096984 72676 59360 S 13.33 0.448 0:01.94 akonadi_contact 679 root 20 0 218820 81664 80512 S 6.667 0.503 0:03.45 systemd-journal 2145 neo 20 0 1143360 62280 47272 S 6.667 0.384 0:31.48 kactivitymanage 2148 neo 20 0 1159148 67968 54748 S 6.667 0.419 0:02.14 org_kde_powerde PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1980 neo 20 0 4071252 244208 133384 R 62.50 1.504 2:57.60 kwin_x11 2107 neo 20 0 6442812 624076 197856 S 62.50 3.843 15:37.47 plasmashell 1452 root 20 0 1216088 126060 76812 S 56.25 0.776 2:46.10 Xorg.bin 1972 neo 20 0 1097276 77936 63400 S 18.75 0.480 0:16.39 ksmserver 12349 neo 20 0 3035032 255420 158452 S 12.50 1.573 0:02.64 kscreenlocker_g 1799 neo 20 0 1093792 73212 59544 S 6.250 0.451 0:01.90 kwalletd6 2145 neo 20 0 1143360 62280 47272 S 6.250 0.384 0:31.79 kactivitymanage 2292 neo 20 0 235160 8056 7288 S 6.250 0.050 0:01.87 at-spi2-registr PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1980 neo 20 0 4071252 243936 133384 S 62.50 1.502 3:04.44 kwin_x11 2107 neo 20 0 6440764 624076 197856 S 62.50 3.843 15:43.80 plasmashell 1452 root 20 0 1222232 126060 76812 S 56.25 0.776 2:52.19 Xorg.bin 1972 neo 20 0 1097276 77936 63400 S 18.75 0.480 0:18.34 ksmserver 12349 neo 20 0 2916208 255420 158452 S 12.50 1.573 0:03.29 kscreenlocker_g 1799 neo 20 0 1093792 73212 59544 S 6.250 0.451 0:02.07 kwalletd6 2101 neo 20 0 194536 22448 20016 S 6.250 0.138 0:02.02 kscreen_backend 2150 neo 20 0 194356 21580 19532 S 6.250 0.133 0:02.09 xembedsniproxy PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1980 neo 20 0 4071252 244380 133384 S 73.33 1.505 3:11.29 kwin_x11 2107 neo 20 0 6442812 624076 197856 S 66.67 3.843 15:50.11 plasmashell 1452 root 20 0 1222232 126060 76812 S 60.00 0.776 2:58.27 Xorg.bin 1972 neo 20 0 1097276 77936 63400 R 20.00 0.480 0:20.29 ksmserver 1979 neo 20 0 2084420 95360 75428 S 6.667 0.587 0:03.73 kded6 2396 neo 20 0 1087976 66796 53548 S 6.667 0.411 0:03.98 kaccess 2619 neo 20 0 1089680 69456 55972 S 6.667 0.428 0:03.28 akonadi_control 2777 neo 20 0 1096984 72676 59360 S 6.667 0.448 0:02.48 akonadi_contact ``` I ran ' sudo true; sleep 10; sudo perf record -p $(pidof kwin_x11) -g -- sleep 30' and got the following result: https://drive.google.com/file/d/1WlRQpT0Mu7v_zdm-sli6tD4TY2t7YDl_/view?usp=drivesdk Also, could this be realted to https://bugs.kde.org/show_bug.cgi?id=484323 ?? (In reply to Yutao Meng from comment #5) > Same here on Arch Linux with kwin_x11 6.0.3.1-2. However, unlike bug report > 484323, it doesn't require external monitors. That was just a theory :) Comment #14 on that other ticket confirmed that it happened with and without external monitor. > It just need at least one > window at maximized status or multiple windows overlapped (have parts one > over another). For me it happens even without any windows open. > And this will only happen at the first run of kwin after sddm > (not yet tested on other DM). If kwin was restart by systemd or manual > command "kwin_x11 --replace" which will not restart sddm, it will not have > high CPU usage after lock screen. I can confirm that observation on my system. If I restart kwin_x11 (only tried manually) it behaves afterwards I'm not sure if I'm seeing the same issue. I do see high CPU usage after I've locked the session, but I only for my old/existing user login, if I try a newer user login, then the problem does not occur. (X11, nvidia 550.67, plasma 6.0.3). In my case I suspect there is something in the old user's config that is the cause. If you're experiencing the issue, it might be worth creating a new user and seeing if that login also experiences the issue. I removed various CPU/Memory tracking widgets, that seemed to resolve the issue, and putting them back reverted the behaviour. But adding the same widgets to the newer account did not replicate the issue, so it's not as simple as that. Perhaps it's a combo of settings, such as floating-panel + widgets or some other setting. Also I think switching to a text console might trigger similar symptoms without needing to lock the session. If I switch to a text console, plasma-shell periodically burns CPU - but it is not constant. *** This bug has been marked as a duplicate of bug 484323 *** |