SUMMARY kactivitymanagerd runs one CPU core at 100% from the moment of login and until logout. This is new behaviour which wasn't present under Plasma 5.27; it's only recently with the upgrade to 6.0.x. STEPS TO REPRODUCE 1. Log in. 2. Open up System Monitor, or better yet, htop from the terminal. 3. Notice that kactivitymanagerd is running constantly at 100%. 4. From the terminal, stop the daemon by executing this and notice that the CPU is now normal: systemctl --user stop plasma-kactivitymanagerd OBSERVED RESULT System Monitor/htop shows one core fully utilitzed by kactivitymanagerd. Also laptop power usage is increased and the fan is coming on more often. EXPECTED RESULT kactivitymanagerd should be at a negligible CPU usage. Laptop fan does not come on at idle. SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-26-generic (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 6800H with Radeon Graphics Memory: 14.9 GiB of RAM Graphics Processor: AMD Radeon Graphics
Update on this with Plasma 6.2.4, Frameworks 6.9.0, Qt 6.8.1 under Wayland... I am still seeing this behavior but it's less frequent than before. Currently, the 100% CPU core usage occurs about 1/10th the time it used to happen when initially reported. It's still strange to see it happening at all, but at least now it's not running full bore almost all the time.
Continuing to notice that kactivitymanagerd will run periodically at 100%, using up one full core. It runs for several seconds and then disappears as if nothing happens. Then about ~85 seconds later, it will run hot again for ~16 seconds. It does this if plasma-systemmonitor is open or not. BTW, plasma-systemmonitor only uses about 0.5% CPU when displaying a page with 5 graphs updating every second.
Thanks for the bug report, and I'm sorry we were not able to get to it yet! Can you check and see if it still happens on Plasma 6.3.4 or later? Thanks a lot!
(In reply to Nate Graham from comment #3) > Thanks for the bug report, and I'm sorry we were not able to get to it yet! > Can you check and see if it still happens on Plasma 6.3.4 or later? Thanks a > lot! Yes and no. I need to figure out why I'm still seeing this same behavior under my regular user account running Plasma 6.3.4 but not on my test user account on the same computer. I've added one extra page to the stock System Monitor, and I'll need to experiment with and without it.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. 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. Closing as RESOLVED WORKSFORME.
Created attachment 184276 [details] gdb backtrace of kactivitymanagerd while cpu runs high I have the same problem: kactivitymanagerd spikes on high CPU usage on one core. I have investigated a bit: I can get kactivitymanager to work on low cpu by doing: $ systemctl --user restart plasma-kactivitymanagerd.service but once I switch between activities, by using my custom shortcut meta+tab (“Walk through activities”), the CPU spikes and stays high. This is a ltrace: $ ltrace -p $(pidof kactivitymanagerd) _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x55d3a27f3568, 0x7fffffffffffffff, 0x100000000, 0x7ffdc8b92d90) = 1 _ZN14QReadWriteLock6unlockEv(0x55d3a27f3568, 0x7fffffffffffffff, 0x55d3a2865c40, 0x55d3a28080c0) = 1 _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x55d3a27f3568, 0x7fffffffffffffff, 0x100000000, 0x7ffdc8b92d90) = 1 _ZN14QReadWriteLock6unlockEv(0x55d3a27f3568, 0x7fffffffffffffff, 0x55d3a2865c40, 0x55d3a28080c0) = 1 _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x55d3a27f3568, 0x7fffffffffffffff, 0x100000000, 0x7ffdc8b92d90) = 1 _ZN14QReadWriteLock6unlockEv(0x55d3a27f3568, 0x7fffffffffffffff, 0x55d3a2865c40, 0x55d3a28080c0) = 1 _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x55d3a27f3568, 0x7fffffffffffffff, 0x100000000, 0x7ffdc8b92d90) = 1 _ZN14QReadWriteLock6unlockEv(0x55d3a27f3568, 0x7fffffffffffffff, 0x55d3a2865c40, 0x55d3a28080c0) = 1 _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x55d3a27f3568, 0x7fffffffffffffff, 0x100000000, 0x7ffdc8b92d90) = 1 And a gdb backtrace is attached (' gdb -batch -ex "thread apply all bt" -p $(pidof kactivitymanagerd)')
reopening as per last comment with backtrace.
I was able to work around this issue because I found this bug report [https://bugs.kde.org/show_bug.cgi?id=470026]. It had to do with an overly large ~/.local/share/recently-used.xbel file that was never being trimmed or the reset from System Settings.
Great, glad you figured out the root cause! *** This bug has been marked as a duplicate of bug 470026 ***