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

(In reply to Méven Car from comment #21)
> Created attachment 168734 [details]
> flamegraph-custom-tab

I noticed the cpu time spent read proc /smaps_rollup to evaluate memory usage is very important in particular.
It is run in a separate thread but this thread is very busy since read will block until the kernel puts together the file.
An asynchonous read of some sort should help things (io_uring, poll...).

A blocking read shouldn't be using CPU unless it's actually reading something. In this case, the CPU time spent by the read call is the time the kernel spends building smaps_rollup. I'd love a better solution for that but it's the interface we have. So far the only improvements I could think of is to spread out how many updates we run in a single "update" cycle and to generally reduce the number of times reading smaps_rollup runs.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/libksysguard/-/merge_requests/353

As I mentioned before, even just reducing the default polling to 2 seconds goes a long way in reducing the CPU usage. While this won't fix current installations, it will help with new ones. All other monitoring tools appear to use a similar polling interval.
I also wonder what the tool used by Méven would say about other monitors such as GNOME's. In theory, if the issue is with the kernel, all monitors should behave the same, but that's not what happens.

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

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

There always has been a resource issue with ksysguard and plasma-systemmonitor!
It's just much more notable in plasma-systemmonitor.
Some people say the fix is to reduce the sampling rate, reading files or heck even throw in io_uring as a "solution". No.
plasma-systemmonitor sucks up an easy 50% across all cores. That is in any tab.

Look at btop (https://github.com/aristocratos/btop) for example. In it's options (General -> Update ms) set it to 500ms. That very much over the top (pun intended) system monitor ONLY sucks up ~3% at that setting. Before anyone even thinks: "ohh, I bet it uses io_uring for that"... No, it doesn't! It uses:
- standard C++ ifstream
- does NOT use smaps_rollup, instead seems to be getting that from each individual pid in the stat, statm and smaps file. Little difficult to figure out precisely without diving in deep.

So something is very very very very wrong in plasma-systemmonitor for it to behave so bad that it takes up 50% on all cores.

Sidenote. The plasma-systemmonitor cpu usage is erratic. I've seen it - just while writing this message! - consume just a few percentages all the way up to 50%...

Plasma systemmonitor takes up nearly a whole core (of a Ryzen 9 5950X) even when just monitoring sensor data (lm_sensors). No process listing etc. is monitored.

There is something severely wrong it with, surely just reading the sensor data and rendering the graphs can not be that CPU intensive?

I've double-checked and all other tabs are set to load only if selected.

Hi,

So since my last post i've been hacking away at this (taking btop as starting point) to figure out how accurate (as in how many snapshots per second) i can do without progress monitoring itself becomes noise in the monitoring making the monitoring itself more complicated.

Turn out that reading the data from all stat files for each pid (so /proc/1/stat, /proc/2/stat, /proc/3/stat, ...) is amazingly fast. I tried this on my machine with about 350 running processes and reading all those files every 100ms (so 10x per second) is not any significant CPU usage at all. As in, it barely even registers! It's even hard to say how much CPU it uses as it's essentially 0% with occasional very short jumps to 2%.

I tried this with normal open/read/close and with io_uring!
There's hardly any difference!

The number of syscalls/second (350 processes with open/read/close = 350*3=1050 syscalls per second when instrumenting once per second.
I reduced this to about 100 syscalls with io_uring (io_uring_enter is the one mostly used, it's to submit data to "the ring"), again when instrumenting once per second.

io_uring vs plain open/read/close?
Don't bother!

The amount of extra code you need (and the massive added code complexity) is not worth it.
The benefits in terms of performance are negligible at best. So again, io_uring is not worth it!

Just wanted to put this on here to prevent someone from wasting hours implementing io_uring just to discover that it's not gonna matter at all. The progress monitor is doing something, i don't know what, incredible inefficient but IO is quite likely not the culprit. Unless the wrong files are polled of course.

Git commit 1f48d7e9c420a40372b7ecfaf20d99d2e876168c by Méven Car.
Committed on 17/07/2024 at 11:52.
Pushed by meven into branch 'master'.

processes_linux_p: ensure to have a single smaps read runnable

In case the vmaps computation lasts more than the timeout
(updateDurationMS currently 2 seconds), ensure to not enqueue another
smaps read runnable for the process.

M  +6    -4    processcore/processes_linux_p.cpp

https://invent.kde.org/plasma/libksysguard/-/commit/1f48d7e9c420a40372b7ecfaf20d99d2e876168c

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

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

FWIW I can pretty much reproduce this. The app idles at 21-25% CPU for me constantly.

I think this shows we shouldn't use vmaps to compute memory usage.
Albeit the best data we can get, we should either lower its frequency update or use another method altogether.

https://invent.kde.org/plasma/libksysguard/-/commit/1f48d7e9c420a40372b7ecfaf20d99d2e876168c impact should be negligible.

(In reply to Méven Car from comment #35)
> I think this shows we shouldn't use vmaps to compute memory usage.
> Albeit the best data we can get, we should either lower its frequency update
> or use another method altogether.
> 
> https://invent.kde.org/plasma/libksysguard/-/commit/
> 1f48d7e9c420a40372b7ecfaf20d99d2e876168c impact should be negligible.

I just went through a bit of libksysguard and ksysguard.
And gave up.

In the past i would've spend days (weeks even) profiling this, finding the bottleneck and finding ways to solve it.
Now... I don't see a point.

The current "plasma-systemmonitor", while visually good looking, has become a heavy program to run. It's gui "feels" sluggish (think of how sluggish java apps feel, that's how i experience plasma-systemmonitor).

And making changes has become close to rocket science because the codebase of this and libksysguard are huge for what they do.
Also, did we "need" a redesigned ksysguard? I liked the old look too (which was refreshed!).

I also tried to recompile the last version of ksysguard (the gui) but that is impossible as ksysguard (the library) doesn't work anymore due to some qml qt6 only thing (fails in the cmake step).

The solution you propose (extending the update frequency) makes the whole app even more useless. When i open a system monitoring tool i want to see what's going on. Setting that update to 2 seconds effectively smooths out short spikes that you would have seen at half a second. That's useless.

My unsolicited, and perhaps a bit harsh, advice:
- Go back to a situation where it was usable. Meaning revert to ksysguard from KDE 5.x and set aside plasma-systemmonitor because it is obviously not suited for the task it's meant to serve. ksysguard had less issues so back to a point from where it's better at least.
- Meanwhile, really thoroughly think about plasma-systemmonitor. The fact that it has panels/pages/edits is "awesome"... but come on, do we really need that in a system monitor? That's a lot of extra functionality that is just wasted for plasma-systemmonitor. It would be a thousand times better suited for kmail for example.
- Simplify the codebase. A LOT! Take btop as an example.
- Aim to have a 500ms update frequency at barely any cpu usage (btop can while still being super flexible. There's no reason why plasma-systemmonitor can't)

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

Just for the people ranting here: ksysguard and plasma-systemmonitor use the same code to gather data about processes (libprocesscore from libksysguard)

(In reply to David Redondo from comment #39)
> Just for the people ranting here: ksysguard and plasma-systemmonitor use the
> same code to gather data about processes (libprocesscore from libksysguard)

It is, however, true that KSysGuard consumes a lot less CPU resources, even if it is based on the same libraries. I have just tested this, and System Monitor consumes between two and three times the CPU. So while I think it is safe to say that there are indeed architectural issues in libksysguard, there are *more* issues specific to System Monitor which appear to compound over the library ones.
To be specific, on my system (which hasn't changed since I opened this report three and a half years ago), System Monitor uses about 60% of one core, KSysGuard uses about 30%, BPyTop uses 5%.

(In reply to David Redondo from comment #39)
> Just for the people ranting here: ksysguard and plasma-systemmonitor use the
> same code to gather data about processes

Just for the people defending systemmonitor here (also marking comments mentioning alternatives as spam, putting systemmonitor in every release screenshot, etc.)... Yes. We know. That's not the problem.
Plasma-systemmonitor not only uses considerably more resources than ksysguard, its UI becomes *completely unusable* if the system is heavily loaded. 
These problems are readily apparent, trivial to reproduce, and being regularly reported by multiple users.

I suspect from the comments (someone involved in the project correct me if I'm wrong) that System Monitor will not be fixed. It's codebase seems too hairy, no-one seems to actually know what the real issue is properly. Note: as I've said before, the **bulk** of the problem is not gathering process information, although I'm fairly certain that problem also has problems. The CPU usage is abnormally high when just drawing sensors information from lm-sensors.

Generally, bug listings should be reserved for comments only relevant working towards fixing the issue. However if this seems unlikely, comments about alternatives should be allowed (IMHO); so the comments marked as spam should not be marked as such. I don't see much ranting here.

I've already moved on to alternatives. Projects such as btop (for terminal) coolercontrol work well for showing sensor information.

I'd be interested in any efforts/projects to start from scratch building a working monitoring application for KDE Plasma. I don't know if I'd be able to contribute, but I've used a lot of different monitoring applications (geared for servers and desktops alike) and know of a few caveats, in addition to resource usage. For example, there's a long-standing (from ksysguard) issue of assuming static structures in /sys/class/hwmon (see bug #466277), which get's exacerbated every year since more and more devices get lm-sensors support (my computer has 7-9 hwmon devices, depending on which USB devices I have plugged in). For a to-be application, a list of minimum set of requirements should be made before starting any development work (judging from the state of Plasma System Monitor, this was not the case when it was developed).

I see no comment i'd consider spam. But i do see some being marked as such. It's sad imho.
Much of the comments here are criticism but in a, in my opinion, fair manner. 

I think it's oke to criticize a product where it's intended purpose isn't working as intended. 

(In reply to Ville Aakko from comment #42)
> I suspect from the comments (someone involved in the project correct me if
> I'm wrong) that System Monitor will not be fixed. It's codebase seems too
> hairy, no-one seems to actually know what the real issue is properly. Note:
> as I've said before, the **bulk** of the problem is not gathering process
> information, although I'm fairly certain that problem also has problems. The
> CPU usage is abnormally high when just drawing sensors information from
> lm-sensors.
> 
> Generally, bug listings should be reserved for comments only relevant
> working towards fixing the issue. However if this seems unlikely, comments
> about alternatives should be allowed (IMHO); so the comments marked as spam
> should not be marked as such. I don't see much ranting here.
> 
> I've already moved on to alternatives. Projects such as btop (for terminal)
> coolercontrol work well for showing sensor information.
> 
> I'd be interested in any efforts/projects to start from scratch building a
> working monitoring application for KDE Plasma. I don't know if I'd be able
> to contribute, but I've used a lot of different monitoring applications
> (geared for servers and desktops alike) and know of a few caveats, in
> addition to resource usage. For example, there's a long-standing (from
> ksysguard) issue of assuming static structures in /sys/class/hwmon (see bug
> #466277), which get's exacerbated every year since more and more devices get
> lm-sensors support (my computer has 7-9 hwmon devices, depending on which
> USB devices I have plugged in). For a to-be application, a list of minimum
> set of requirements should be made before starting any development work
> (judging from the state of Plasma System Monitor, this was not the case when
> it was developed).

I'd be interested in building such a project too.
The tricky thing isn't even building the library. Just fork the part from btop and you already nearly have it.

The tricky part is not screwing up the performance in the GUI layers to represent that data.

The current UI is super configurable with even drag/drop. Someone must have spend many weeks on that i'd assume. I'm not saying that on it's own is bad. A new library behind the scenes isn't going to make things magically faster. I'd be confident in saying that 99% of the current time is spend outside the metric collection (and thus in the UI).  To me, all the stuff in the backend and UI is just waaaaay to hairy! I'm not even gonna try and touch that as it's just gonna take days (weeks probably) to refactor it.

Thank you for letting us know that there is a KSysGuard KF6 port even though dirty (https://github.com/zvova7890/ksysguard6/tree/kf6)! It seems clear to me what should happen:
- Remove plasma-systemmonitor and work on it behind the scenes (re-introduce it later on when it's not a resource hog anymore)
- Temporary revert back to KSysGuard

There's probably a bit of pride involved here too for whoever wrote plasma-systemmonitor and rightfully so! It's a beautiful product (in screenshots). But as it stands, it's just not functionally usable so the wise thing to do is go back to what worked. It's not like there hasn't been time, plasma-systemmonitor has been there for some years already. It's just a component that doesn't have many devs  (https://invent.kde.org/plasma/plasma-systemmonitor look at the commits, it's essentially unmaintained) so fixing it isn't gonna happen in the near future it seems.

Bugzilla isn't a forum, it's a place for bugs to be tracked and discussed with a bias towards getting them resolved. We know this is an issue; that's why it's open and in the CONFIRMED state. Further criticisms don't help anything. if you want to help, try to fix it. If you can't, then the most helpful thing you can do is avoid publicly complaining on the bug tracker.

(In reply to Nate Graham from comment #44)
> if you want to help, try to fix it. If you can't, then the most
> helpful thing you can do is avoid publicly complaining on the bug tracker.

Is a return of KSysGuard acceptable?
If you can get behind that then I'll happily put in the time to make the PR for exactly that (somewhere in november/december).

I'm just not willing to try and waste many hours if it turns out to be a no.

I marked a comment as spam not because of mentioning of alternatives but the clear violation of the code-of-conduct.

The lm-sensors information being is interesting and new to me. As I never heard about or seen it in a flamegraph and very surprising as ksysguard or plasma-systemmonitor dont interact with lmsensors themselbes but ksystemstats and ksysguardd do.

As a general point of information the more rude the conversation in a bug report the less likely developers are inclined to look at it and fix it. Nobody wants to spend their (often free!) time reading a heated discussion or be or their product being insulted.

I don't consider it heated, contested or hostile at all...

Anyhow, the offer stands. If a return of KSysGuard is acceptable then I'm willing to put in the time and effort to get that done.
It is not a long term solution, I know that. It's an intermediary fix till plasma-systemmonitor is in good shape again.

(In reply to Nate Graham from comment #44)
> We know this is an issue; that's
> why it's open and in the CONFIRMED state. Further criticisms don't help
> anything. if you want to help, try to fix it.

Thanks for acknowledging the issues. I think by making the new system monitor the default while it still has such tremendous regressions compared to the old one, it's easy to think that the gravity the change had on some users was not anticipated.

> Nobody wants to spend their (often free!) time reading [...] their product being insulted.

I love the optics of the new system monitor. Do you personally consider the new one a suitable replacement of the old one in the near future, though?

I can get behind the "the old one wasn't maintained" reasoning, and I'm really happy y'all have already resolved many of the ~10 bug reports I raised about the new one (as constructively as I could). Meanwhile since you're asking for empathy towards maintainers, is it difficult to conversely see that users would be unhappy to see such massive usability downgrades in everyday tooling?

Wouldn't it save a lot of energy for all of us if we let these things bake a little bit further instead of over-eagerly changing defaults? I've had the same sentiment for the QML rewrite of the KCM modules, where the end result turned out to be a great improvement in the long run but the initial roll-outs had been very bumpy.

> Anyhow, the offer stands. If a return of KSysGuard is acceptable then I'm willing to put in the time and effort to get that done.
It is not a long term solution, I know that. It's an intermediary fix till plasma-systemmonitor is in good shape again.

I'd also really appreciate if this proposal could be nodded off. I do want to see the new applet return one day, or perhaps shipped side-by-side (as I think it already was at least on my distribution).

(In reply to neobrain from comment #50)
> (In reply to Nate Graham from comment #44)
> > We know this is an issue; that's
> > why it's open and in the CONFIRMED state. Further criticisms don't help
> > anything. if you want to help, try to fix it.
> 
> Thanks for acknowledging the issues. I think by making the new system
> monitor the default while it still has such tremendous regressions compared
> to the old one, it's easy to think that the gravity the change had on some
> users was not anticipated.
> 
> > Nobody wants to spend their (often free!) time reading [...] their product being insulted.
> 
> I love the optics of the new system monitor. Do you personally consider the
> new one a suitable replacement of the old one in the near future, though?
> 
> I can get behind the "the old one wasn't maintained" reasoning, and I'm
> really happy y'all have already resolved many of the ~10 bug reports I
> raised about the new one (as constructively as I could). Meanwhile since
> you're asking for empathy towards maintainers, is it difficult to conversely
> see that users would be unhappy to see such massive usability downgrades in
> everyday tooling?
> 
> Wouldn't it save a lot of energy for all of us if we let these things bake a
> little bit further instead of over-eagerly changing defaults? I've had the
> same sentiment for the QML rewrite of the KCM modules, where the end result
> turned out to be a great improvement in the long run but the initial
> roll-outs had been very bumpy.

That is a rational way to think but not how most open source is developed in general. And, frankly, for good reasons too. Open source is volunteer free own time dev work which very often is a dev passionate about something and building it. That passion is a lot harder to keep up when your feature works but it's not performing well. It's the good old 80-20 rule. They can do 80% of the work (the new feature) in 20% of the time and are happy about it. The remaining 20% takes 80% of the time and is fine tuning it to a point where it works well and stable. It's this 20% where open source very often falls short. I get it! I have that "bad habit" too.

Usually in releases though this is being caught by people who test or by people who are very picky about new changes. I'm guessing plasma-systemmonitor went through without that. That is still fine too! But given that this very bur report is from early 2021 it should've been obvious that replacing KSysGuard with plasma-systemmonitor was not the best decision and that the default should've been ksysguard where plasma-systemmonitor would be available too.
> 
> > Anyhow, the offer stands. If a return of KSysGuard is acceptable then I'm willing to put in the time and effort to get that done.
> It is not a long term solution, I know that. It's an intermediary fix till
> plasma-systemmonitor is in good shape again.
> 
> I'd also really appreciate if this proposal could be nodded off. I do want
> to see the new applet return one day, or perhaps shipped side-by-side (as I
> think it already was at least on my distribution).

I'd encourage the side-by-side approach too. With ksysguard being the default!

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

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