Date: Wed, 27 May 1998 13:31:46 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: sbabkin@dcn.att.com Cc: danj@3skel.com, freebsd-hackers@FreeBSD.ORG, dnelson@emsphone.com Subject: Re: Load avg 0.33 and 99.2% idle... Message-ID: <199805271731.NAA18001@hda.hda.com> In-Reply-To: <C50B6FBA632FD111AF0F0000C0AD71EEFF8AED@dcn71.dcn.att.com> from "sbabkin@dcn.att.com" at "May 27, 98 12:35:41 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> It sounds weird to me. The program doing select() sleeps like
> any others and do not reside in the run queue. But, on the
> other hand, the load computations are based on sampling on
> timer interrupts, so if some program is activated on time
> intervals, like select() with timeout, the timer interrupt
> will encounter longer run queue because itself had woken up
> these processes and placed them into the run queue right
> before computing the load. I think this explanation is
> closer to reality.
I think:
The load average computation is done synchronously
at the HZ clock tick by looking at the length of the run queue
while the idle stats are done asynchronously, and all
the timeouts are rounded to the clock tick (at least nanosleep
works that way). So:
main()
{
while (1)
usleep(1);
}
will be in the run queue at each tick so the load average is 1,
but the system is essentially 100% idle since this process goes
right back to sleep. If this process were woken up at a higher
resolution timer than the scheduling time quantum, preempting the
current process, the idle time would go down.
Peter
--
Peter Dufault (dufault@hda.com) Realtime development, Machine control,
HD Associates, Inc. Safety critical systems, Agency approval
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805271731.NAA18001>