Red Hat Bugzilla – Bug 132091
The total percentages in top are displayed incorrently in SMP systems.
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Description of problem:
The updated procps package from EL3 update 3 incorrectly displays the
total percentages in top. It looks like the total percentages are now
sums, so they are often over 100%. The pre-update 3 package,
procps-2.0.13-9.2E, correctly showed the total percentages.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run the top command.
Actual Results: CPU states: cpu user nice system irq
softirq iowait idle
total 109.0% 0.6% 12.4% 0.0% 0.0% 0.0% 77.2%
cpu00 35.7% 0.0% 1.5% 0.0% 0.0% 0.0% 62.6%
cpu01 73.4% 0.7% 10.9% 0.1% 0.0% 0.0% 14.5%
Expected Results: CPU states: cpu user nice system irq
softirq iowait idle
total 20.5% 0.0% 20.5% 0.0% 0.4% 0.0% 58.3%
cpu00 36.5% 0.0% 32.6% 0.0% 0.9% 0.0% 29.8%
cpu01 4.8% 0.0% 7.6% 0.0% 0.0% 0.0% 87.5%
this is actually not a bug but a feature. The reason for displaying
percents above the 100% limit is that if you enable Irix/Solaris view
mode, for instance by 'I' keyboard shortcut in top, it won't display
mean percentage of cpu load of all cpus but summed all the cpu loads
Is pressing 'I' in top fixing your problem?
I think, I fix in current CVS for RHEL-3/procps-2.0.17, so it should
be available in the current errata as soon as possible.
The problem was with "unsigned long" usage, kernel 2.4 returns data
that are < 0 in the top counting..
*** Bug 134377 has been marked as a duplicate of this bug. ***
I am not sure if this should be a separate bug ticket or not, but
since it also seems to be a bug in the latest version of procps/top in
RHEL3, I decided to just add it to my original bug. Memory
calculations also seem to be way off, here is a portion of my top
output (sorted by memory usage):
Mem: 509876k av, 476372k used, 33504k free, 0k shrd,
352436k actv, 45844k in_d, 6920k in_c
Swap: 1044216k av, 270220k used, 773996k free
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
8729 smithj4 15 0 630M 629M 6264 S 0.0 126.4 2:13 1 gaim
6232 smithj4 15 0 571M 564M 5316 S 0.1 113.3 42:11 0
5148 smithj4 15 0 324M 319M 16416 S 0.0 64.1 50:58 1
4726 smithj4 15 0 300M 297M 4468 S 0.0 59.8 20:02 0
24717 smithj4 15 0 259M 259M 5056 S 0.0 52.0 37:59 0 gkrellm
4625 root 15 0 496M 236M 8964 S 0.5 47.5 351:27 0 X
4472 root 15 0 56180 54M 540 S 0.0 11.0 0:00 0 crond
First, according to top, just a few processes are using more memory
that my system has (real + swap). Second, ps disagrees with top about
how much memory these processes are using.
Is this related to the same problem first reported? Does your fix in
CVS that you mentioned in comment #4 about unsigned longs also fix
this problem? When will an errata be released for procps, soon or not
until U4? Do you have a package ready that can be tested?
Jason, your report about memory seems as some other problem. Please,
can you report it as separated bug? (no problem if you use cut & past
of your previous description).
The program "ps" uses for PMEM counting 'rss', but "top" uses
'resident' field, so there is possible see differences.
The SIZE and RSS really seems strange in your output, IMHO the problem
is with page shift setting in this old top version. The new versions
(in RHEL4, FC2 or FC3) seems more useful in this case.
This old "top" uses PAGE_SHIFT constant, but more useful is probably
use getpagesize() system call.
Can you compile and test small program from next attachement in your
Please, answer to new bug report. Thanks.
Created attachment 106011 [details]
report system pagesize and PAGE_SHIFT setting
gcc -Wall -o pagesize pagesize.c
Opened separate bug #137927 to address the incorrect memory values
reported by top.
Is the original bug here going to be fixed? I realize that it's just
the "I" toggle, but the fact is that it used to be set correctly for
RHEL3 and now it's not. As I said in bug 134377: "It appears that
the problem here is that the 'I' command is now toggled incorrectly
for SMP systems. With procps 2.0.13, running top produced a correct
display, but with procps 2.0.17 it's necessary to execute the 'I'
command once to fix the display. This default should set back to the
old, correct behavior."
To be clear: the problem I'm talking about is the total percentages
over 100%, not the memory calculations.
The original bug (here) is kernel bug. And bug #134377 is fixed.
I'm not clear on just what you're saying with your response, but I'll
take it to mean that as of the next release of procps top will again
have the correct default for its "I" toggle (and so percentages will
be displayed correctly again). If you have any information on when
that fix will be available, that would be helpful.
Sorry, kernel bug is bug #137927. This bug #132091 is already fixed
and the patch is available in procps-2.0.17-13 (RHEL-3-U4, expected
release time 01-Dec-2004).
CPU percentages are fix to default to "average" instead of "combined" in
2.0.17-13. Will be release in the next series of errata.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.