https://bugs.kde.org/show_bug.cgi?id=470026
--- Comment #11 from Méven <me...@kde.org> --- (In reply to MartinG from comment #9) > I want to add, that I still experience 100 % CPU from kactivitymanagerd > (kactivitymanagerd-6.4.4-1.fc42.x86_64) after moving away > ~/.local/share/recently-used.xbel and doing systemctl --user restart > plasma-kactivitymanagerd.service. I originally posted some more info in > https://bugs.kde.org/show_bug.cgi?id=484837#c7 and I see the same ltrace now: > > $ ltrace -p $(pidof kactivitymanagerd) > ... > _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, > 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) > = 1 > _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, > 0x5584b0473660, 0x5584b04800c0) > = 1 > _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, > 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) > = 1 > _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, > 0x5584b0473660, 0x5584b04800c0) > = 1 > _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, > 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) > = 1 > _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, > 0x5584b0473660, 0x5584b04800c0) > = 1 > This shed some light. Another thing you could do to help debug is to use perf, with for instance hotspot https://github.com/KDAB/hotspot A flamegraph showing where the kactivitymanagerd processus is spending its time during the CPU spike in particular. > > So I'm not convinced this error is related to a big > ~/.local/share/recently-used.xbel alone. Is there anything more I can try? > Also, right now, I see high cpu only on my Default activity - if I switch to > another activity, the cpu usage goes down immediately. If I switch back to > Default, it goes up again. A lock issue could be at hand, lock and unlocking in quick succession could cause this 100% CPU spike. Which lock is concerned. -- You are receiving this mail because: You are watching all bug changes.
