What CPU and GPU are you using?

(In reply to David Redondo from comment #1)
> What CPU and GPU are you using?

It happens on both my notebook, with a Ryzen 5 2500U and Radeon Vega 7 iGPU, and my desktop, with a Ryzen 5 3600 and a Radeon 5700. In both cases I am using kernel 5.11 and Mesa 21.0, in case that's relevant, but it's been like this with KSysGuard as well for a long time and with different kernel and Mesa versions (see bug 429687).

Hmm, so probably not the same thing as Bug 429152, then.

(In reply to Nate Graham from comment #3)
> Hmm, so probably not the same thing as Bug 429152, then.

If it's related, then I guess it's not about the GPU or the resolution as I have a Full-HD monitor.

I run on a Ryzen 2500U as well (it has a Vega 8 btw, not 7 ;) ), the Vega should be sufficiently powerful to handle everything, at least it is in my case. However, you say you're also seeing this with KSysGuard?

Could you post a screenshot of the Applications page with system monitor selected and the "application details" pane visible? Especially the processes table in the details pane would be useful.

Created attachment 137076 [details]
Screenshot with application details

(In reply to Arjen Hiemstra from comment #5)
> I run on a Ryzen 2500U as well (it has a Vega 8 btw, not 7 ;) ), the Vega
> should be sufficiently powerful to handle everything, at least it is in my
> case. However, you say you're also seeing this with KSysGuard?

Oh, right, I got them mixed up. I can play games on this laptop, so I guess there's ample power. The thing is that the issue is there even with my desktop with its Radeon 5700, which has ample power to handle everything.
I see a similar issue with KSysGuard as well, yes. In that case it's the KSysGuard process which uses 30+% CPU. I wonder, not knowing anything about the implementation, if they have libraries in common and if that could be one area to explore...

(In reply to Arjen Hiemstra from comment #6)
> Could you post a screenshot of the Applications page with system monitor
> selected and the "application details" pane visible? Especially the
> processes table in the details pane would be useful.

Sure, please find it in the attachments.

Interesting, the application table reports >50% cpu used, the application details says 6%. Can you confirm that the application table uses the "Line Chart (scaled to 100%)" display style?

> I see a similar issue with KSysGuard as well, yes. In that case it's the KSysGuard process which uses 30+% CPU. I wonder, not knowing anything about the implementation, if they have libraries in common and if that could be one area to explore...

There's a bunch of code shared, among others the data collection for the process statistics. So if there's an issue it seems to be in the shared code.

(In reply to Arjen Hiemstra from comment #8)
> Interesting, the application table reports >50% cpu used, the application
> details says 6%. Can you confirm that the application table uses the "Line
> Chart (scaled to 100%)" display style?
> 
> > I see a similar issue with KSysGuard as well, yes. In that case it's the KSysGuard process which uses 30+% CPU. I wonder, not knowing anything about the implementation, if they have libraries in common and if that could be one area to explore...
> 
> There's a bunch of code shared, among others the data collection for the
> process statistics. So if there's an issue it seems to be in the shared code.

It's not scaled to 100%, it's per-core utilisation which I actually deem far better to understand what's going on. Seeing "12.5%" on my Ryzen 5 2500U doesn't immediately explain why the fan is spinning like crazy, seeing "100%" on a single core does.

In that case it's 50% of one core, which is not different from what mine does. It also means that this is not going to be fixed any time soon, if at all. The problem lies with the complete lack of a kernel API[1] for the statistics that we query, apart from the text files in /proc. This means that every update we have to read the entire /proc directory to determine if there are new processes or if processes have gone away, then for each of these directories read a bunch of text files, parse them and convert that to something that we can use to display data. Moreover, these files are not real files but can potentially do stuff behind our back to provide the text data. One example here is /proc/PID/smaps_rollup which will actually go through a process' memory pages when it is opened and which is one part of the fairly large amount of CPU usage.

[1]: There is actually a kernel interface to get basic process information over netlink, but it has been declared unsafe and can only be accessed by root.

The thing is this behaviour is not there on another desktop I own (to which I have no access right now, due to it being in another country). There, KSysGuard used ~3% CPU as it should.
Let's forget that for a moment though. I understand the complexity that lies below showing these stats, but it seems to me like something very, very inefficient happens in KSysGuard and System Monitor given that GNOME System Monitor, which is equivalent in all respects to the KDE programs, uses ~5% CPU. I don't know what it does differently, but it manages to offer the same basic functionality while using a ton less resources.
I don't think that using >30% CPU to show you how much CPU is being used is in any way acceptable or recommended (as Nate puts it, "a system monitoring app should be as lightweight as possible to avoid mutating what it's measuring"). I will stop using System Monitor and KSysGuard until progress is made on this front as they are the main reason why my notebook's fans spin up and keep on spinning as long as they stay open.

Arjen, I think I have understood why there is excessive CPU usage and I have a proposal on how to fix it. The problem is that System Monitor (and KSysGuard as well, though to a less extent) simply poll the information too often. The difference between Plasma System Monitor, which uses a lot of resources, and GNOME System Monitor, which is quite efficient, is that the latter does not update the data as often, thus using much fewer resources and being much lighter on the system. It is my conviction that by reducing the amount of times the data is updated, a satisfactory balance can be achieved.
Currently System Monitor updates multiple times a second, which is overkill for any practical purposes: nobody needs to see the CPU graph going up and down with such precision, one or two times a second would be more than enough. As far as I understand this, this would involve basically any other application and widget that relies on this features because this is all managed in the KDE Frameworks? Do you reckon reducing the update rate would be feasible?
Let me know. Thanks.

FWIW only what is seen in process and application tables is done in  process. Other data is gathered by ksystemstats and send to plasma-systemmonitor

(In reply to Riccardo Robecchi from comment #12)
> Arjen, I think I have understood why there is excessive CPU usage and I have
> a proposal on how to fix it. The problem is that System Monitor (and
> KSysGuard as well, though to a less extent) simply poll the information too
> often. The difference between Plasma System Monitor, which uses a lot of
> resources, and GNOME System Monitor, which is quite efficient, is that the
> latter does not update the data as often, thus using much fewer resources
> and being much lighter on the system. It is my conviction that by reducing
> the amount of times the data is updated, a satisfactory balance can be
> achieved.
> Currently System Monitor updates multiple times a second, which is overkill
> for any practical purposes: nobody needs to see the CPU graph going up and
> down with such precision, one or two times a second would be more than
> enough. As far as I understand this, this would involve basically any other
> application and widget that relies on this features because this is all
> managed in the KDE Frameworks? Do you reckon reducing the update rate would
> be feasible?
> Let me know. Thanks.

So there are a few things here, one is global information, like CPU usage, network usage and sensors. These are handled by ksystemstats, which runs at an update rate of 500ms. This is passed over DBus to plasma-systemmonitor, which then gets change signals and passes this to sensor objects that record these changes and allow the UI to do its thing. In some cases, like line charts, there's a data source for the chart that requests data from these sensor objects on a regular interval, so that we can display a continuous line chart. Not all these timers run in sync, so you may end up having some staggered updates, but no individual chart should update more frequently than every 500ms. There is also a setting to reduce how often a chart updates. This is only client side, but reduces how often redraws happen.

There is another part, which is the more relevant part here, which is the process data which is provided through ProcessCore. This runs on a timer of two seconds and then reads a whole bunch of system files, parses them and updates all the relevant process files. There's one tricky file in here, which is `/proc/$PID/smaps_rollup` which provides the most accurate memory usage measurement of a process, in the form of the "proportional set size" value. Unfortunately, it also turns out to be a slight bit of a minefield: when opened, the kernel goes through the entire memory mapping of a process to accumulate the needed values. This turns out to be a rather expensive operation, especially when doing it for all the running processes. This is actually the main source of CPU usage you're seeing.

I have done some work the other day on being able to disable this part of the process data collection, by disabling the "memory" column from the UI. The library parts are all there, but right now the UI in plasma-systemmonitor requires the memory column for the details pane, which I do not have a solution for yet. Once that is done, you could disable the memory column and replace it with something like "private usage" to get rid of most of the CPU usage.

Thank you for your detailed answer. I didn't know it was possible to manually set the update period, so thanks for that information. I've made an experiment which appears to confirm what I was thinking, and that is that the main culprit behind the high CPU usage is actually the way the graphs are dawn in the application. Mind you, this is empirical and anecdotal evidence, so of course take it with a pinch of salt. 

I tried looking at the update frequency setting in the UI and changed it to 1 second for all the graphs where I could do it (in the overview and in history, plus in a page I set up with hardware temperature graphs). The result is actually a drastic reduction in CPU usage. Whereas the default behaviour hovers around 30-35% single-core CPU usage, changing the update timer to 1 second lowers it to about 15%, even when opening all of those pages and therefore making the app draw all of them. While still a bit high, this is much more acceptable.

While your proposed changes in the library might help bring the CPU usage down even further, I suggest changing the default update timer for graphs to 1 second anyway. You can try it yourself on your machine, but I see this vast improvement on my main laptop (Ryzen 5 2500U), on my desktop (Ryzen 5 3600), as well as on my tablet (a Dell Venue 11 Pro 7140 with an Intel Core M-5Y10c). Advantages are admittedly more limited on the desktop and on the tablet, where CPU usage was already low (around 10%), but the change brings it down to less than 5%; in the case of the tablet, CPU usage went down from an average of 10% to 3%, which is quite significant. Memory consumption is also reduced, which appears to be a nice, free bonus.

To add to this bug report, I believe System Monitor's whole UI is affected by this, regardless of a graph being present or not. Updating window content via moving graphs or just scrolling the processes list is very expensive to the CPU.

Going on the default 'Processes' page and scrolling the processes page (with no graphs enabled) will easily spike the CPU usage to 40%+. Doing the same thing in KSysGuard will only raise ~7% at most. Is it that GPU rendering isn't happening at all?


Operating System: openSUSE Leap 15.3
KDE Plasma Version: 5.24.2
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.3.18-150300.59.49-default (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-3320M CPU @ 2.60GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4000

I'm also experiencing the same: systemmonitor makes my fan activate even if not interacting with it.

In systemmonitor itself, it only shows to be using 2-3% CPU, but that is of all cores. Given that I have 16 cores (Ryzen 4750U), it amounts to 35-50% of a single core (checked with htop). htop itself is much less CPU-intensive for comparable functionality. On my system systemmonitor is the single most CPU-consuming application during light desktop use and I have to use MS teams… Even Firefox with five windows and about 50 open tabs uses less CPU unless interacting with complex/dynamic content.

This is still an issue. It's because of this specific issue where the plasma-systemmonitor app always uses 50% CPU of one core that I always used the older "systemmonitor" app.

It's a real bummer that the older "systemmonitor" app got removed in favor of this new one, even though the new one is still really flawed. 
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3471

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.90.0
KDE Frameworks Version: 5.246.0
Qt Version: 6.6.1
Kernel Version: 6.7.0-rc5-1-mainline
Graphics Platform: Wayland
Graphics Drivers: mesa 23.3.1
Processors: AMD Ryzen 9 4900HS
Memory:  24GB of RAM
Graphics Processor: Integrated: Vega 8
Manufacturer: ASUS (Zephyrus G15 GA502IV)

*** Bug 479740 has been marked as a duplicate of this bug. ***

Created attachment 168733 [details]
flamegraph

On my Intel laptop using the kwin paint effect (Ctrl+F11).
I can see in the processor tab the application constantly blinking, switching to the Overview, and observe high CPU usage.

I am using plasma-monitor 6.0.4 on plasma 6.1-dev.
Here joined a flamegraph of 5 seconds in the process tab.

Operating System: Arch Linux 
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.5.0-1-mainline (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15.1 Gio of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Manufacturer: Dell Inc.
Product Name: XPS 13 9370

Created attachment 168734 [details]
flamegraph-custom-tab