Bug 448626

Summary: When slowly copying files via KIO sometimes CPU spikes to non-sense values for a fraction of a second
Product: [Applications] plasma-systemmonitor Reporter: postix <postix>
Component: generalAssignee: KSysGuard Developers <ksysguard-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: ahiemstra, plasma-bugs, postix
Priority: NOR    
Version: 5.25.2   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.24.1
Sentry Crash Report:
Attachments: Screenrecording
Plot 1
Plot 1

Description postix 2022-01-16 22:30:03 UTC
Created attachment 145561 [details]
Screenrecording

SUMMARY

I copied a ~500 MB zip file to by an USB reader attached microSD card. The progressbar was immediately at 100% but it took about two minutes until the data was actually completely transferred.  

During these two minutes I could observe a handful of non-sense spikes in the CPU load like 600.806.4....%.
You can see it in the screen recording of the system monitor's applet at second 7.

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20220114
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.16.0-1-default (64-bit)
Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor
Comment 1 Arjen Hiemstra 2022-02-03 15:55:39 UTC
CPU usage is calculated by reading `/proc/stat` and subtracting the previous value from the current value. The sudden large value suggests that suddenly the new value is less than the previous value, which would lead to integer overflow like that. Can you run `watch -n 0.5 cat /proc/stat` and see if the values jump back at some point?
Comment 2 postix 2022-02-03 21:06:01 UTC
Created attachment 146237 [details]
Plot 1

(In reply to Arjen Hiemstra from comment #1)
> Can you run `watch -n 0.5 cat /proc/stat` and see if the values jump back at some point?

Yes, I have collected the data via 
`watch -n 0.1 "(date && cat /proc/stat) >> procstat.log` 
with higher resolution than probably needed.

The data I have plotted graphically via a Python script and if I did not make a mistake [1] there are several negative values.
While I had recorded the data set, I counted about 4 possible overflows.

[1] https://paste.debian.net/plainh/8f3de29c
Comment 3 postix 2022-02-03 21:49:43 UTC
Created attachment 146240 [details]
Plot 1
Comment 4 Bug Janitor Service 2022-02-04 13:57:42 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksystemstats/-/merge_requests/32
Comment 5 Nate Graham 2022-02-04 15:50:55 UTC
Git commit f3f509fca64f6806f5e2533b5e7ab7907a7e6746 by Nate Graham, on behalf of Arjen Hiemstra.
Committed on 04/02/2022 at 15:50.
Pushed by ngraham into branch 'master'.

CPU Plugin: Prevent integer overflow of total usage

In some cases, the values we read from the system can result in a
negative difference to the previous values. This was already guarded
partially, but only for system/user/wait usage. Total usage would still
be able to go negative, resulting in overflow of the total usage.

Instead, ensure that all the differences are always at least 0, so if we
add things together we aren't adding negatives.
FIXED-IN: 5.24.1

M  +16   -7    plugins/cpu/usagecomputer.cpp

https://invent.kde.org/plasma/ksystemstats/commit/f3f509fca64f6806f5e2533b5e7ab7907a7e6746
Comment 6 Nate Graham 2022-02-04 15:51:30 UTC
Git commit 99670f3a2ec04037da341e5ae11cbc481c799f35 by Nate Graham, on behalf of Arjen Hiemstra.
Committed on 04/02/2022 at 15:51.
Pushed by ngraham into branch 'Plasma/5.24'.

CPU Plugin: Prevent integer overflow of total usage

In some cases, the values we read from the system can result in a
negative difference to the previous values. This was already guarded
partially, but only for system/user/wait usage. Total usage would still
be able to go negative, resulting in overflow of the total usage.

Instead, ensure that all the differences are always at least 0, so if we
add things together we aren't adding negatives.
FIXED-IN: 5.24.1


(cherry picked from commit f3f509fca64f6806f5e2533b5e7ab7907a7e6746)

M  +16   -7    plugins/cpu/usagecomputer.cpp

https://invent.kde.org/plasma/ksystemstats/commit/99670f3a2ec04037da341e5ae11cbc481c799f35
Comment 7 postix 2022-07-08 18:28:02 UTC
Unfortunately I can reproduce it again while doing some backup to some USB attached HDD, now on Plasma 5.25.5.
Comment 8 postix 2022-07-08 19:48:51 UTC
Maybe a saver check would be

```        
if (tickDiff > totalDiff &&  totalDiff > 0) {
            return 100.0 * tickDiff / totalDiff;
        }
        return 0.0;
```
Comment 9 postix 2022-07-08 19:49:53 UTC
I meant of course
```      
if (tickDiff < totalDiff &&  tickDiff > 0) {
```
Comment 10 Arjen Hiemstra 2023-01-26 14:38:58 UTC
Git commit d6b5d4aa7ac95712c1602deb9d2df4b6d4d8a878 by Arjen Hiemstra.
Committed on 26/01/2023 at 13:21.
Pushed by ahiemstra into branch 'master'.

Ensure we only ever use tick differences that don't exceed the total

We know they'll be wrong if they exceed the total.

M  +2    -2    plugins/cpu/usagecomputer.cpp

https://invent.kde.org/plasma/ksystemstats/commit/d6b5d4aa7ac95712c1602deb9d2df4b6d4d8a878