Bug 185994 - Top "Cpu0" line never updates when using "Single Cpu = Off" option on single processor machine
Top "Cpu0" line never updates when using "Single Cpu = Off" option on single ...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: procps (Show other bugs)
6
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Tomas Smetana
Brian Brock
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-20 15:17 EST by Robert Jackson
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: 3.2.7-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-20 08:05:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix single cpu statistics for non-SMP systems (567 bytes, patch)
2006-03-20 17:52 EST, Robert Jackson
no flags Details | Diff
CPU0 patch for procps 3.2.7 in FC6 (634 bytes, patch)
2007-09-07 16:52 EDT, Robert Jackson
no flags Details | Diff

  None (edit)
Description Robert Jackson 2006-03-20 15:17:41 EST
Description of problem:

By default, top displays a CPU usage summary for all CPUs on a single line, e.g.:

Cpu(s):  1.0% us,  0.0% sy,  0.0% ni, 99.0% id,  0.0% wa,  0.0% hi,  0.0% si

Pressing "1" changes this to display separate lines for each CPU, e.g. for a
single processor machine:

Cpu0  : 12.2% us,  3.2% sy,  0.0% ni, 84.7% id,  0.0% wa,  0.0% hi,  0.0% si

This works fine when used interactively (i.e. by pressing "1").

But when this configuration is saved to a .toprc file (by pressing "W"), and top
is restarted, the Cpu0 line will not update, regardless of the system load.

If "1" is pressed twice to toggle the display mode to Cpu(s) and back to Cpu0,
then it starts updating correctly.

Also note this problem only occurs on single processor machines (I've confirmed
it on several i386 and x86_64 machines using UP kernels).  On SMP machines,
separate lines are displayed for Cpu0 and Cpu1, which update correctly.


Version-Release number of selected component (if applicable):

procps-3.2.5-6.3


How reproducible:

Consistently when following steps below.


Steps to Reproduce:

1. Use a single processor machine with UP kernel
2. Remove ~/.toprc file
3. Run "top"
4. Press "1" to toggle "Single Cpu" mode
5. Press "W" to save ~/.toprc
6. Close "top"
7. Reopen "top"
8. Cpu0 line will not update.

  
Actual results:

Cpu0 line doesn't update.


Expected results:

Cpu0 line does update.


Additional info:
Comment 1 Robert Jackson 2006-03-20 17:52:27 EST
Created attachment 126367 [details]
Fix single cpu statistics for non-SMP systems
Comment 2 Robert Jackson 2006-03-20 17:53:26 EST
After some investigation, I've found the problem.

[Note I've been using the source of procps-3.2.6-3.2 from FC5]

At the end of function summaryhlp on line 2882 of top.c, the current values of
the counters are stored, so the difference can be computed when the function is
called again.  These old values are stored as cpu->u_sav, cpu->s_sav, ... ,
cpu->y_sav.

Then in the function cpus_refresh on line 909 of top.c, the "if" statement on
line 978 copies the total CPU stats (stored in cpus[1]) to CPU0 (stored in
cpus[0]) for non-SMP systems (to workaround an issue with kernel 2.2.xx).

Unfortunately this clobbers the old saved values (cpus[0]->u_sav, etc).  This
avoid this, copy only the latest values, and leave the saved values alone.

Note also that the CPU0 statistics are always wrong on non-SMP, even when they
appear to be refreshing, because the saved values never get updated.  I believe
you'll actually end up with an average usage, rather than current usage.

Patch in Comment #1
Comment 3 Karel Zak 2006-03-20 19:53:44 EST
Ah.. you're right. Nobody complains probably because nobody on non-SMP use "list
of CPUs" :-)
Comment 4 Karel Zak 2006-03-20 20:00:34 EST
BTW, I think this problem is valid for all 3.x procps versions and probably
exists pretty long time. Good catch!
Comment 5 Fedora Update System 2006-06-01 10:27:36 EDT
procps-3.2.5-6.4 has been pushed for fc4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 6 Robert Jackson 2006-06-03 08:42:41 EDT
The updated package procps-3.2.5-6.4 fixes this issue for me.  Thanks.
Comment 7 Robert Jackson 2007-09-07 16:51:45 EDT
Unfortunately this bug has reappeared in FC6 (and probably FC7 & above).

I suspect it was reintroduced in 3.2.6-4 when the patch
procps-3.2.5-top-cpu0.patch was merged into procps-3.2.7-top-remcpu.patch

The attached patch (applied on top of procps-3.2.7-top-remcpu.patch) fixes the
issue again in procps-3.2.7-11.fc6 for me.

However there may be a better solution since the "just in case we're 2.2.xx" if
statement is now duplicated in two places in top.c

I would appreciate it if this fix could be added to procps in FC6 before its EOL.

Thanks

Robert
Comment 8 Robert Jackson 2007-09-07 16:52:46 EDT
Created attachment 190511 [details]
CPU0 patch for procps 3.2.7 in FC6
Comment 9 Fedora Update System 2007-09-17 23:24:33 EDT
procps-3.2.7-16.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 Tomas Smetana 2007-09-20 08:05:29 EDT
The patch was also applied on FC-6 package that should be out already.

Note You need to log in before you can comment on or make changes to this bug.