Bug 107339 - top shows 0% CPU usage for niced processes
Summary: top shows 0% CPU usage for niced processes
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-17 02:35 UTC by Konstantin Olchanski
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-20 13:21:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Konstantin Olchanski 2003-10-17 02:35:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

Description of problem:
"top" incorrectly shows 0% CPU usage for "nice"ed processes. vmstat shows
correct cpu usage, "top" "CPU states" display shows correct cpu usage.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run "nice -10 ./eatcpu.exe" (see source code below)
2. run "top"
3. observe high cpu usage in the "cpu nice" state display
4. observe high load average
5. observe "eatcpu.exe" incorrectly showing 0% cpu usage in the per-process display

Additional info:

Source code for eatcpu.exe:

[olchansk@tw00 utils]$ cat ./eatcpu.c 
/* eatcpu.c */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc,char*argv[])
  while (1)
      /* do nothing */


/* end file */
[olchansk@tw00 utils]$ g++ -o eatcpu.exe -g -O0 eatcpu.c
[olchansk@tw00 utils]$ nice -10 ./eatcpu.exe 


Comment 1 Konstantin Olchanski 2003-10-17 02:38:26 UTC
Forgot to attach the incorrect "top" output while running "nice -10 ./eatcpu.exe":

 19:40:24  up 8 days,  5:17,  4 users,  load average: 1.04, 0.41, 0.25
75 processes: 73 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    0.0%  100.0%    0.0%   0.0%     0.0%    0.0%  100.0%
           cpu00    0.0%    0.0%    0.0%   0.0%     0.0%    0.0%  100.0%
           cpu01    0.0%  100.0%    0.0%   0.0%     0.0%    0.0%    0.0%
Mem:  2037152k av, 1632696k used,  404456k free,       0k shrd,  230768k buff
                    434500k actv,   65012k in_d,   35684k in_c
Swap: 4096564k av,      16k used, 4096548k free                  664644k cached

 1466 olchansk  15   0  1336 1336   948 R     0.0  0.0   0:00   0 top
 1495 olchansk  35  10   768  768   664 R N   0.0  0.0   0:00   1 eatcpu.exe


Comment 2 Alexander Larsson 2003-10-17 07:51:00 UTC
ugh. pretty bad.

Comment 3 Alexander Larsson 2003-10-17 08:02:05 UTC
Hmm, arjan claimed he has seen similar bugs that have been fixes in later kernel
versions. Might be fixed already.

Comment 4 Alexander Larsson 2003-10-17 08:31:15 UTC
Yeah. I don't get this with kernel 2.4.21-2.ELsmp and procps-2.0.13-9.2E.
What kernel are you using? Can you try a later one?

Comment 5 Konstantin Olchanski 2003-10-18 23:41:51 UTC
Too many different versions floating around.

I have kernel 2.4.21-1.1931.2.393.entsmp and procps-2.0.13-9E. Where do I get
the rpms you guys mention?

Amd64 Rawhide has procps-2.0.17-1. I installed it and it has the same problem.

Amd64 Rawhide has kernel-2.4.20-9.2, older than the one you mention
(2.4.21-2.ELsmp) and older than what I run (2.4.21-1.1931.2.393.entsmp). Should
I try it?

BTW, I am confused by the "taroon" versions. What came with the machine claims
to be "Red Hat Enterprise Linux release 2.9.5WS (Taroon)". Is this "beta",
"beta2" or what?


Comment 6 Alexander Larsson 2003-10-20 09:17:28 UTC
I'm really not sure about the kernel versions. I'm reassigning to kernel so
someone who knows about this can reply.

Comment 7 Matt Wilson 2003-10-20 13:21:58 UTC
this was fixed in kernel, latest is in RHN

Comment 8 Konstantin Olchanski 2003-10-30 00:30:25 UTC
I confirm that the problem does not exist with kernel-smp-2.4.21-4.EL (from
RHEL3.0) and procps-2.0.17-1 (from Rawhide). K.O.

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