Bug 484837

Summary: kactivitymanagerd runs one CPU core at 100% under Plasma 6.0, laptop fan runs at idle
Product: [Plasma] plasmashell Reporter: Michael <kde>
Component: Activities in generalAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED DUPLICATE    
Severity: major CC: gronslet, ivan.cukic, nate, plasma-bugs-null
Priority: NOR    
Version First Reported In: 6.2.5   
Target Milestone: 1.0   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: gdb backtrace of kactivitymanagerd while cpu runs high

Description Michael 2024-03-31 20:35:11 UTC
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
Comment 1 Michael 2024-12-20 07:40:50 UTC
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.
Comment 2 Michael 2025-01-09 04:42:48 UTC
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.
Comment 3 Nate Graham 2025-05-08 16:12:38 UTC
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!
Comment 4 Michael 2025-05-10 00:20:56 UTC
(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.
Comment 5 Bug Janitor Service 2025-05-25 03:48:19 UTC
🐛🧹 ⚠️ 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!
Comment 6 Bug Janitor Service 2025-06-09 03:47:27 UTC
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
Comment 7 MartinG 2025-08-20 07:09:00 UTC
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)')
Comment 8 MartinG 2025-08-20 08:48:07 UTC
reopening as per last comment with backtrace.
Comment 9 Michael 2025-08-26 01:51:25 UTC
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.
Comment 10 Nate Graham 2025-08-26 18:04:13 UTC
Great, glad you figured out the root cause!

*** This bug has been marked as a duplicate of bug 470026 ***