Bug 448626 - When slowly copying files via KIO sometimes CPU spikes to non-sense values for a fraction of a second
Summary: When slowly copying files via KIO sometimes CPU spikes to non-sense values fo...
Status: REOPENED
Alias: None
Product: plasma-systemmonitor
Classification: Plasma
Component: general (show other bugs)
Version: 5.25.2
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-16 22:30 UTC by postix
Modified: 2022-07-08 19:49 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24.1


Attachments
Screenrecording (35.25 KB, video/x-matroska)
2022-01-16 22:30 UTC, postix
Details
Plot 1 (1007.38 KB, image/png)
2022-02-03 21:06 UTC, postix
Details
Plot 1 (1008.09 KB, image/png)
2022-02-03 21:49 UTC, postix
Details

Note You need to log in before you can comment on or make changes to this bug.
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) {
```