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
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?
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
Created attachment 146240 [details] Plot 1
A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksystemstats/-/merge_requests/32
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
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
Unfortunately I can reproduce it again while doing some backup to some USB attached HDD, now on Plasma 5.25.5.
Maybe a saver check would be ``` if (tickDiff > totalDiff && totalDiff > 0) { return 100.0 * tickDiff / totalDiff; } return 0.0; ```
I meant of course ``` if (tickDiff < totalDiff && tickDiff > 0) { ```
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