From owner-freebsd-hackers Wed May 27 10:57:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20074 for freebsd-hackers-outgoing; Wed, 27 May 1998 10:57:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA19919 for ; Wed, 27 May 1998 10:56:01 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id NAA18001; Wed, 27 May 1998 13:31:47 -0400 (EDT) From: Peter Dufault Message-Id: <199805271731.NAA18001@hda.hda.com> Subject: Re: Load avg 0.33 and 99.2% idle... In-Reply-To: from "sbabkin@dcn.att.com" at "May 27, 98 12:35:41 pm" To: sbabkin@dcn.att.com Date: Wed, 27 May 1998 13:31:46 -0400 (EDT) Cc: danj@3skel.com, freebsd-hackers@FreeBSD.ORG, dnelson@emsphone.com X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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