Red Hat Bugzilla – Bug 185994
Top "Cpu0" line never updates when using "Single Cpu = Off" option on single processor machine
Last modified: 2007-11-30 17:11:27 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):
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.
Cpu0 line doesn't update.
Cpu0 line does update.
Created attachment 126367 [details]
Fix single cpu statistics for non-SMP systems
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, ... ,
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) to CPU0 (stored in
cpus) for non-SMP systems (to workaround an issue with kernel 2.2.xx).
Unfortunately this clobbers the old saved values (cpus->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
Ah.. you're right. Nobody complains probably because nobody on non-SMP use "list
of CPUs" :-)
BTW, I think this problem is valid for all 3.x procps versions and probably
exists pretty long time. Good catch!
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.
The updated package procps-3.2.5-6.4 fixes this issue for me. Thanks.
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.
Created attachment 190511 [details]
CPU0 patch for procps 3.2.7 in FC6
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.
The patch was also applied on FC-6 package that should be out already.