Created attachment 229707 [details] Screenshot: 98% Shortly after launch, CPU usage by the application rises to 100% (measured by htop) with occasional minor drops. % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #115 main-n250650-ef396441ceb: Sat Nov 13 23:52:09 GMT 2021 root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400041 1400041 %
Created attachment 229731 [details] screenshot: 100% after removing everything For a while, it seemed that excessive usage occurred only when the Overview tab was active. Whenever I clicked the History tab, usage dropped. Then whenever I reviewed the Overview, usage skyrocketed to 100%; as if viewing History was a workaround. After removing everything from the Overview tab, usage no longer dropped when History was viewed. After removing/hiding _everything_, usage remained excessive. Attached: a screenshot from near the end of a 7.9 MiB screen recording.
(In reply to Graham Perrin from comment #0) > … 14.0-CURRENT … Around thirty percent (less excessive) reported by a user of 13.0-RELEASE at and under <https://forums.freebsd.org/posts/543488>.
Created attachment 236179 [details] Screenshot: Processes tab plasma5-plasma-systemmonitor-5.24.6 not using excessive CPU. Operating System: FreeBSD 14.0 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 14.0-CURRENT (64-bit) Graphics Platform: X11 Memory: 15.9 GiB of RAM Graphics Processor: AMD TURKS % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #19 main-n257401-82493ff7007a: Tue Aug 16 05:16:20 BST 2022 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400065 1400065 %
Created attachment 236180 [details] Screenshot: Overview tab
Is this still relevant with Plasma 6?
Thanks for asking. The HP EliteBook 8570p that I used for the 2021 report has been written off. I switched to Kubuntu (HP ZBook 17 G2) … FreeBSD in VirtualBox guests on a mobile hard disk drive on USB. Not an environment that's suitable for commenting on performance. Can someone else tell? Maybe with a relatively old computer and spinning rust.
The bug is still relevant.
*** Bug 290046 has been marked as a duplicate of this bug. ***
Created attachment 264376 [details] only start the cgroupdatamodel if available is true This decreases the cpu usages significantly. I did not investigate too much what causes an enabled but not available appModel to have high cpu usage...
(In reply to Jesper Schmitz Mouridsen from comment #9) Unmodified The interval of the QTimer m_updateTimer CGroupDateModelPrivate is zero when it is started in setEnabled, the problem is that https://github.com/KDE/libksysguard/blob/ff14c3b7086d3dcdce479b5041947a739904374d/processcore/cgroup_data_model.cpp#L110 returns before changing the default zero interval to 2000 ms.. It turns out even a not connected to QTimer::timeout a started QTimer with interval 0 causes high cpu usage..
(In reply to Jesper Schmitz Mouridsen from comment #10) Thanks for the hint, I'll try to look into this issue in near days.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fef45ca5f0e3495cf41153b6a4cf201ed4317832 commit fef45ca5f0e3495cf41153b6a4cf201ed4317832 Author: Gleb Popov <arrowd@FreeBSD.org> AuthorDate: 2025-10-13 15:02:59 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-10-13 15:04:50 +0000 sysutils/plasma6-libksysguard: Fix busy-looping in process handling code PR: 260029 Reported by: jsm (finding the root of the issue) sysutils/plasma6-libksysguard/Makefile | 1 + .../patch-processcore_cgroup__data__model.cpp (new) | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)