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 general | Assignee: | 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
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 *** |