This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: 'top' command always reports 0.0% cpu usage
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: Chris January <chris at atomice dot net>
- Cc: cygwin-apps at cygwin dot com
- Date: Fri, 17 Feb 2006 12:14:07 +0100
- Subject: Re: 'top' command always reports 0.0% cpu usage
- References: <261998F8FB9AF44B80638C240CF14A5A01CEF66F@EXCHANGE1.mexico.tem.mx>
- Reply-to: cygwin-apps at cygwin dot com
Hi Chris,
On Feb 16 15:56, Manuel Gonzalez Montoya wrote:
> All,
>
> I just installed the lastest cygwin version on an XP Professional
> SP2 machine and noticed the output of the top command always reports
> wrong info (0.0%) about the CPU usage summary as you can see in the
> example:
>
> Tasks: 10 total, 1 running, 9 sleeping, 0 stopped, 0 zombie
> Cpu0 : 0.0% user, 0.0% system, 0.0% nice, 0.0% idle
> Mem: 522776k total, 308740k used, 214036k free, 0k buffers
> Swap: 2097152k total, 70060k used, 2027092k free, 0k cached
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 3080 manuel.g 8 0 22976 20m 448 R 3.5 3.9 0:59.29 top
> 2304 manuel.g 8 0 28416 1216 0 S 0.0 0.2 0:00.59 bash
> 2920 manuel.g 8 0 16640 26m 1344 S 0.0 5.2 0:00.09 man
> 2148 manuel.g 8 0 26112 43m 832 S 0.0 8.6 0:00.06 sh
> 3380 manuel.g 8 0 24640 33m 960 S 0.0 6.6 0:00.06 sh
> 684 manuel.g 8 0 26432 46m 1024 S 0.0 9.1 0:00.07 sh
> 900 manuel.g 8 0 19520 26m 1152 S 0.0 5.1 0:00.04 less
> 3828 manuel.g 8 0 15936 26m 832 S 0.0 5.2 0:00.06 groff
> 3252 manuel.g 8 0 29440 24m 896 S 0.0 4.9 0:00.40 bash
> 3936 manuel.g 8 0 23552 31m 640 S 0.0 6.1 0:00.21 grotty
>
>
> Is that an error or just the normal behavior?
I investigated this problem and it turns out that top is relying on
undocumented behaviour.
What it does to read /proc/stat is this, basically:
if (!fp)
fp = fopen ("/proc/stat", "r");
rewind(fp);
fflush(fp);
fread(fp);
It relies on the fact that a rewind/fflush would call lseek. However,
this might be true for glibc, but it's not true for newlib. If the
file pointer is opened for reading only, the fseek function called by
rewind optimizes the lseek call away, if it can satisfy the seek within
the given FILE buffer. Then it relies on fflush clearing the buffer
to force another underlying read call, but that, too, is undefined
behaviour, since fflush is only documented to do something of value,
if the file pointer is opened for writing.
So, what I did to circumvent the reliance on undefined behaviour is
to set the file pointer to unbuffered mode:
if (!fp)
{
fp = fopen ("/proc/stat", "r");
setvbuf (fp, NULL, _IONBF, 0);
}
rewind(fp);
fflush(fp);
fread(fp);
That works nicely, obviously. Would you mind to release a new version
of procps with the above or a similar patch?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat