Bug 304145 - Ridiculously high peaks in CPU usage graph
Summary: Ridiculously high peaks in CPU usage graph
Status: REPORTED
Alias: None
Product: ksysguard
Classification: Applications
Component: ksysguard (show other bugs)
Version: 4.8
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
: 332704 385017 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-27 15:05 UTC by flakinho
Modified: 2022-08-18 19:45 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot of the program with a peak (68.88 KB, image/png)
2012-07-27 15:06 UTC, flakinho
Details
Another screenshot (64 bit system) (129.59 KB, image/png)
2014-03-28 01:41 UTC, nicknackgus
Details
Another example of erroneously high CPU usage spikes (21.40 KB, image/png)
2018-05-02 16:37 UTC, Ville Aakko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description flakinho 2012-07-27 15:05:09 UTC
After updating from Ubuntu 11.10 to 12.04, I am getting very high peaks for a single processor in the CPU usage graph. Something like 9e+09%, even when I specify the graph to keep the scale between 0 and 100%.
It happens really often, about 1 per 5 mins, and randomly through the different CPUs of my laptop.

Reproducible: Always
Comment 1 flakinho 2012-07-27 15:06:03 UTC
Created attachment 72789 [details]
Screenshot of the program with a peak
Comment 2 Christoph Feck 2014-03-28 01:29:36 UTC
*** Bug 332704 has been marked as a duplicate of this bug. ***
Comment 3 nicknackgus 2014-03-28 01:37:58 UTC
Same, but I'm getting something more like 1E19 under what sounds like identical circumstances. I got sent here because someone (Christoph Feck) noticed my bug report was a duplicate. My processor is an Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz, in a laptop. I have also confirmed this is a problem for the Intel(R) Pentium(R) CPU G645 @ 2.90GHz, in a desktop, and have an amd desktop waiting to be tested.
I'm certain it's a software problem now, but in case it's specific to Intel processors, could you check your processor info? (cat /proc/cpuinfo)
Comment 4 nicknackgus 2014-03-28 01:41:09 UTC
Created attachment 85800 [details]
Another screenshot (64 bit system)
Comment 5 nicknackgus 2014-03-28 01:45:28 UTC
I also noticed that the highest unsigned 64bit int is roughly equal to 1.8E19, and the highest unsigned 32bit int is roughly equal to 4.3E9. I suspect that we've got a negative number in here somehow, which would wrap around to the large numbers we're seeing. I haven't seen the code yet to test this theory.
Comment 6 flakinho 2014-03-28 14:09:37 UTC
Here it is:
$ cat /proc/cpuinfo



processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 2200.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.75
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 1
initial apicid	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.59
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 2201.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 1
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.61
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 1
cpu cores	: 4
apicid		: 3
initial apicid	: 3
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.60
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 4
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 2
cpu cores	: 4
apicid		: 4
initial apicid	: 4
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.60
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 5
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 2
cpu cores	: 4
apicid		: 5
initial apicid	: 5
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.60
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 6
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.60
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 7
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x28
cpu MHz		: 900.000
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 3
cpu cores	: 4
apicid		: 7
initial apicid	: 7
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4385.61
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
Comment 7 Christoph Feck 2014-04-20 21:54:38 UTC
I am unsure if I am looking at the right source code, but at kde-workspace/ksysguard/ksysguardd/Linux/stat.c line 164 it could compute negative values, if any of the counters wraps around. This would mean that those counters are increasing REALLY fast.

Could you please add the output of "grep '^cpu' /proc/stat" for some invokations spaced about one second apart?
Comment 8 flakinho 2014-04-21 16:28:13 UTC
Something like this?

for a in 1 2 3 4 5 6 7; do sleep 1; date; grep '^cpu' /proc/stat; done

Mon Apr 21 12:27:05 EDT 2014
cpu  90931 365445 106650 777845 18865 0 894 0 0 0
cpu0 17623 35054 18691 87809 8896 0 823 0 0 0
cpu1 8159 48836 11002 100952 1412 0 0 0 0 0
cpu2 16369 41623 14413 95276 2470 0 5 0 0 0
cpu3 7898 50888 8997 101100 1428 0 2 0 0 0
cpu4 14255 41869 16586 95966 1434 0 3 0 0 0
cpu5 5344 56169 8432 99458 972 0 2 0 0 0
cpu6 14923 40472 15626 97929 1051 0 56 0 0 0
cpu7 6357 50532 12900 99352 1196 0 0 0 0 0
Mon Apr 21 12:27:06 EDT 2014
cpu  90955 365445 106662 778615 18865 0 894 0 0 0
cpu0 17625 35054 18696 87901 8896 0 824 0 0 0
cpu1 8159 48836 11002 101053 1412 0 0 0 0 0
cpu2 16371 41623 14417 95369 2470 0 5 0 0 0
cpu3 7898 50888 8997 101201 1428 0 2 0 0 0
cpu4 14260 41869 16586 96062 1434 0 3 0 0 0
cpu5 5345 56169 8432 99558 972 0 2 0 0 0
cpu6 14931 40472 15628 98020 1051 0 56 0 0 0
cpu7 6362 50532 12901 99449 1196 0 0 0 0 0
Mon Apr 21 12:27:07 EDT 2014
cpu  90976 365445 106671 779389 18865 0 894 0 0 0
cpu0 17635 35054 18699 87987 8896 0 824 0 0 0
cpu1 8159 48836 11002 101153 1412 0 0 0 0 0
cpu2 16374 41623 14422 95462 2470 0 5 0 0 0
cpu3 7898 50888 8997 101301 1428 0 2 0 0 0
cpu4 14262 41869 16586 96160 1434 0 3 0 0 0
cpu5 5346 56169 8432 99658 972 0 2 0 0 0
cpu6 14933 40472 15628 98118 1051 0 56 0 0 0
cpu7 6365 50532 12901 99546 1196 0 0 0 0 0
Mon Apr 21 12:27:08 EDT 2014
cpu  90995 365445 106682 780161 18865 0 894 0 0 0
cpu0 17643 35054 18703 88075 8896 0 824 0 0 0
cpu1 8159 48836 11002 101254 1412 0 0 0 0 0
cpu2 16378 41623 14424 95556 2470 0 5 0 0 0
cpu3 7898 50888 8997 101402 1428 0 2 0 0 0
cpu4 14270 41869 16590 96249 1434 0 3 0 0 0
cpu5 5346 56169 8432 99759 972 0 2 0 0 0
cpu6 14934 40472 15629 98216 1051 0 56 0 0 0
cpu7 6365 50532 12902 99646 1196 0 0 0 0 0
Mon Apr 21 12:27:09 EDT 2014
cpu  91016 365445 106692 780931 18867 0 895 0 0 0
cpu0 17649 35054 18706 88161 8899 0 825 0 0 0
cpu1 8159 48836 11002 101355 1412 0 0 0 0 0
cpu2 16384 41623 14427 95648 2470 0 5 0 0 0
cpu3 7898 50888 8997 101503 1428 0 2 0 0 0
cpu4 14274 41869 16592 96344 1434 0 3 0 0 0
cpu5 5346 56169 8432 99860 972 0 2 0 0 0
cpu6 14937 40472 15631 98311 1051 0 56 0 0 0
cpu7 6365 50532 12902 99747 1196 0 0 0 0 0
Mon Apr 21 12:27:10 EDT 2014
cpu  91039 365445 106706 781694 18867 0 897 0 0 0
cpu0 17659 35054 18711 88245 8899 0 826 0 0 0
cpu1 8160 48836 11002 101455 1412 0 0 0 0 0
cpu2 16389 41623 14429 95741 2470 0 5 0 0 0
cpu3 7898 50888 8997 101603 1428 0 2 0 0 0
cpu4 14278 41869 16595 96438 1434 0 3 0 0 0
cpu5 5349 56169 8432 99957 972 0 2 0 0 0
cpu6 14939 40472 15634 98406 1051 0 56 0 0 0
cpu7 6365 50532 12902 99847 1196 0 0 0 0 0
Mon Apr 21 12:27:11 EDT 2014
cpu  91060 365445 106718 782460 18867 0 898 0 0 0
cpu0 17667 35054 18717 88327 8899 0 828 0 0 0
cpu1 8160 48836 11002 101555 1412 0 0 0 0 0
cpu2 16395 41623 14432 95832 2470 0 5 0 0 0
cpu3 7898 50888 8997 101703 1428 0 2 0 0 0
cpu4 14282 41869 16597 96532 1434 0 3 0 0 0
cpu5 5349 56169 8432 100057 972 0 2 0 0 0
cpu6 14940 40472 15635 98505 1051 0 56 0 0 0
cpu7 6365 50532 12902 99946 1196 0 0 0 0 0


(In reply to comment #7)
> I am unsure if I am looking at the right source code, but at
> kde-workspace/ksysguard/ksysguardd/Linux/stat.c line 164 it could compute
> negative values, if any of the counters wraps around. This would mean that
> those counters are increasing REALLY fast.
> 
> Could you please add the output of "grep '^cpu' /proc/stat" for some
> invokations spaced about one second apart?
Comment 9 Christoph Feck 2014-04-22 21:41:01 UTC
Thanks, this confirms what I was suspecting. These counters do not increase fast enough to explain a 32-bit wrap every couple of minutes.
Comment 10 Ville Aakko 2018-05-02 16:37:01 UTC
Created attachment 112377 [details]
Another example of erroneously high CPU usage spikes

Hi,

This is still an issue on KSysguard 5.12.5 (Arch, Plasma 5.12).

Just a guess, but maybe this is related to Bug #238331 ? Including I/O wait time might confuse the computing somemtimes? I tried a few quick test by making my hard disks sleep and then making some file system operations to wake them up, but that didn't reproduce this. So maybe this hypothesis is just a red herring, unless someone knows otherwise just ignore it :-). 

All I know this still happends but I have no idea how to reproduce at will (which would make it easier to debug this).
Comment 11 Hadrien G. 2019-02-20 10:09:49 UTC
A very good reproducer for this bug is to run a IO-intensive and synchronous workload, such as "hdparm -t --direct /dev/<your drive>" or "dd bs=2M count=2000 if=/dev/zero of=test conv=fdatasync && rm test".
Comment 12 Richard Llom 2019-03-11 11:09:32 UTC
*** Bug 385017 has been marked as a duplicate of this bug. ***