Bug 290687 - The summary of cpu load never stops increasing
Summary: The summary of cpu load never stops increasing
Status: RESOLVED FIXED
Alias: None
Product: ksysguard
Classification: Unclassified
Component: Plasmoid / Applet (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR normal with 25 votes (vote)
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
: 292037 293357 295930 298129 299636 301344 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-05 12:55 UTC by regisg
Modified: 2016-04-27 09:09 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.4


Attachments
wrong CPU usage (104.37 KB, image/png)
2012-04-04 13:03 UTC, Dmitry
Details
Remove parent-id check in order to allow 'init' to be updated. (590 bytes, patch)
2012-06-06 12:03 UTC, Carlo Vanini
Details

Note You need to log in before you can comment on or make changes to this bug.
Description regisg 2012-01-05 12:55:57 UTC
Version:           unspecified (using Devel) 
OS:                Linux

The first line which shows init cpu load never stops increasing in 30 seconds, it is at 250%, if I wait it continues climbing

Reproducible: Always

Steps to Reproduce:
launch the app

Actual Results:  
cpu load never ending increasing

Expected Results:  
show the real cpu load
Comment 1 regisg 2012-01-07 11:16:25 UTC
same problem with rc2
Comment 2 John Tapsell 2012-01-07 13:27:55 UTC
Don't suppose you know why? :-)

Is there anything unusual about your system at all?  And ideas why that could be happening?
Comment 3 regisg 2012-01-07 15:19:14 UTC
I don't know what's happening. standalone kysguard is ok. Top gives me a normal cpu load...
Comment 4 Carlo Vanini 2012-01-11 22:06:07 UTC
I'm using version 4.7.97 (Kubuntu Pargolin) and experience the same problem.
It looks to me that the increase is the actual value it should get.

It looks like it computes
new_value += load
instead of
new_value = load.

Probably (just guessing) the new load value at every update is computed as the sum of the load of all processes, including init itself.
Comment 5 Christoph Feck 2012-01-26 16:09:32 UTC
*** Bug 292037 has been marked as a duplicate of this bug. ***
Comment 6 Martin Koller 2012-01-27 23:04:12 UTC
confirmed with 4.8.0, openSuse 12.1
Comment 7 Jekyll Wu 2012-02-05 13:29:08 UTC
*** Bug 293357 has been marked as a duplicate of this bug. ***
Comment 8 davemgv8 2012-02-12 11:40:12 UTC
Confirmed with 4.8.0 ( Slackware current with KDE by Alienbob)

Comment #4 is effect I'm seeing, got in early enough after start to watch it climb through 100%, currently past 40,000 and climbing.
Comment 9 Christoph Feck 2012-03-13 15:39:07 UTC
*** Bug 295930 has been marked as a duplicate of this bug. ***
Comment 10 Dmitry 2012-04-04 13:03:26 UTC
Created attachment 70145 [details]
wrong CPU usage

ksysguard and krunner (Ctrl+Esc) are affected
Comment 11 Christoph Feck 2012-04-16 00:00:14 UTC
*** Bug 298129 has been marked as a duplicate of this bug. ***
Comment 12 Graeme Hewson 2012-05-02 17:30:18 UTC
Confirmed with 4.8.2 (Kubuntu 12.04).
Comment 13 Christoph Feck 2012-05-08 18:34:49 UTC
*** Bug 299636 has been marked as a duplicate of this bug. ***
Comment 14 dE 2012-05-09 11:32:29 UTC
Yes.
Comment 15 Anna Celarek 2012-05-14 21:13:14 UTC
confirm with 4.8.3 (OpenSuse 12.1)
It appears only if display is set to "All Processes, Tree", for the processes systemd and kthreadd which both are top of the tree. 
With "All Processes" (no tree), CPU% for those processes is 0.
Comment 16 Alex Leach 2012-06-06 08:52:20 UTC
Confirmed on Ubuntu server with KDE 4.8.3. I suspect there is also a miscalculation with kthreadd, as well as init. e.g. right now kthreadd shows ~17900% and kthreadd shows 145%. kthreadd is rising by 1% each check interval, wheras init rises by something higher (~30% now, with computer essentially idle). Comment #4 seems a valid interpretation of init's rising CPU usage.
Comment 17 Carlo Vanini 2012-06-06 12:03:42 UTC
Created attachment 71620 [details]
Remove parent-id check in order to allow 'init' to be updated.

When updating a process, there is a check for the id of its parent. When it is < 0 the update fails. The problem is that (by convention) init and kthreadd have parent -1.
Removing the check and relying on QHash<Process*>::value(key) returning Null for a non-existing key fixed the issue. See attachment.

hth
Comment 18 Rolf Eike Beer 2012-06-06 12:09:17 UTC
> Removing the check and relying on QHash<Process*>::value(key) returning
> Null for a non-existing key fixed the issue. See attachment.

The 5 lines shown in the diff could simply be changed to this then:

Process *parent = d->mProcesses.value(ppid, &d->mFakeProcess);
Comment 19 John Tapsell 2012-06-06 12:27:51 UTC
Thank you very much - I committed this to master and KDE/4.8

I was a total block-head though and didn't say the fix was from you
guys in the commit message.  Sorry :-(

Hopefully this will be in on time for the 4.8.4 release.

I used Rolf's one liner change - it would be great if Carlo could
actually try this one liner and check that it works.  I tried myself,
but I could never reproduce the problem anyway.

John

On 6 June 2012 13:09, Rolf Eike Beer <kde@opensource.sf-tec.de> wrote:
> https://bugs.kde.org/show_bug.cgi?id=290687
>
> --- Comment #18 from Rolf Eike Beer <kde@opensource.sf-tec.de> ---
>> Removing the check and relying on QHash<Process*>::value(key) returning
>> Null for a non-existing key fixed the issue. See attachment.
>
> The 5 lines shown in the diff could simply be changed to this then:
>
> Process *parent = d->mProcesses.value(ppid, &d->mFakeProcess);
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are watching the assignee of the bug.
Comment 20 Carlo Vanini 2012-06-06 12:53:12 UTC
> I used Rolf's one liner change - it would be great if Carlo could
> actually try this one liner and check that it works.  I tried myself,
> but I could never reproduce the problem anyway.

I can confirm Rolf's change is working for me.
The problem was visible only in the "All Processes, Tree" view.

thank you.
Comment 21 John Tapsell 2012-06-06 13:02:51 UTC
Thank you again for the fix.  And I'm really sorry that I didn't fix
myself and left this bug in for so very long.
Comment 22 Christoph Feck 2012-06-07 13:31:06 UTC
*** Bug 301344 has been marked as a duplicate of this bug. ***
Comment 23 Jekyll Wu 2012-06-17 22:22:41 UTC
Setting report status correctly.
Comment 24 John Tapsell 2012-06-18 06:51:50 UTC
Thanks - I don't know if the fix actually got into 4.8.4
Comment 25 Graeme Hewson 2012-06-18 07:02:17 UTC
I'm running 4.8.4 and yes, the fix did get into the release.
Comment 26 John Tapsell 2012-06-18 08:33:52 UTC
Excellent to hear :-)