Bug 132091 - The total percentages in top are displayed incorrently in SMP systems.
The total percentages in top are displayed incorrently in SMP systems.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: procps (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
:
: 134377 (view as bug list)
Depends On:
Blocks: 123574
  Show dependency treegraph
 
Reported: 2004-09-08 14:28 EDT by Jason Smith
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-21 14:09:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
report system pagesize and PAGE_SHIFT setting (305 bytes, text/plain)
2004-11-01 09:15 EST, Karel Zak
no flags Details

  None (edit)
Description Jason Smith 2004-09-08 14:28:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040803

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):
procps-2.0.17-10

How reproducible:
Always

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%


Additional info:
Comment 3 Jindrich Novy 2004-10-04 08:56:58 EDT
Jason,

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
together.

Is pressing 'I' in top fixing your problem?
Comment 4 Karel Zak 2004-10-05 10:00:24 EDT
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..
Comment 5 Karel Zak 2004-10-07 08:14:33 EDT
*** Bug 134377 has been marked as a duplicate of this bug. ***
Comment 6 Jason Smith 2004-10-27 14:05:48 EDT
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,  
46496k buff
                    352436k actv,   45844k in_d,    6920k in_c
Swap: 1044216k av,  270220k used,  773996k free                 
150804k cached
                                                                     
                                                                 
  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
gnome-terminal
 5148 smithj4   15   0  324M 319M 16416 S     0.0 64.1  50:58   1
mozilla-bin
 4726 smithj4   15   0  300M 297M  4468 S     0.0 59.8  20:02   0
gnome-panel
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?
Comment 7 Karel Zak 2004-11-01 09:13:36 EST
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
system? 

Please, answer to new bug report. Thanks.
Comment 8 Karel Zak 2004-11-01 09:15:42 EST
Created attachment 106011 [details]
report system pagesize and PAGE_SHIFT setting

gcc -Wall -o pagesize pagesize.c
./pagesize
Comment 9 Jason Smith 2004-11-02 16:36:56 EST
Opened separate bug #137927 to address the incorrect memory values
reported by top.
Comment 10 John Caruso 2004-11-15 12:36:51 EST
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.
Comment 11 Karel Zak 2004-11-16 03:12:27 EST
The original bug (here) is kernel bug. And bug #134377 is fixed.
Comment 12 John Caruso 2004-11-16 19:26:30 EST
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.
Comment 13 Karel Zak 2004-11-17 02:47:00 EST
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).
Comment 14 Jay Turner 2004-12-16 08:11:28 EST
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.
Comment 15 John Flanagan 2004-12-21 14:09:44 EST
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.

http://rhn.redhat.com/errata/RHBA-2004-544.html

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