Bug 132091
Summary: | The total percentages in top are displayed incorrently in SMP systems. | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Jason Smith <smithj4> | ||||
Component: | procps | Assignee: | Karel Zak <kzak> | ||||
Status: | CLOSED ERRATA | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | jcaruso, jturner, tao | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-12-21 19:09:44 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 123574 | ||||||
Attachments: |
|
Description
Jason Smith
2004-09-08 18:28:51 UTC
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? 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, 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? 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. Created attachment 106011 [details]
report system pagesize and PAGE_SHIFT setting
gcc -Wall -o pagesize pagesize.c
./pagesize
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. http://rhn.redhat.com/errata/RHBA-2004-544.html |