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:
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, ... , 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
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. Thanks Robert
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.