Date: Wed, 27 May 1998 16:20:28 -0400 (EDT) From: Dan Janowski <danj@3skel.com> To: Jason Nordwick <nordwick@scam.xcf.berkeley.edu> Cc: sbabkin@dcn.att.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Load avg 0.33 and 99.2% idle... Message-ID: <Pine.BSF.3.96.980527161836.7655A-100000@fnur.3skel.com> In-Reply-To: <356C5E73.F885CBE4@scam.xcf.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
The odd part is that I hadn't noticed this before. I just upgraded to 2.2.6 from 2.2.1. Maybe it's X or some other daemon that is running differently. Dan On Wed, 27 May 1998, Jason Nordwick wrote: > sbabkin@dcn.att.com wrote: > > > > 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. > > > > That raises an interesting issue: should the > > load computation use the average of run queue length before > > and after waking up the time-awaiting processes ? > > > > -Serge > > > > Doesn't the soft (hard?) clock (still dont really know the difference > well) operate on a random jitter to reduce this problem? Or does > that only reduce the ability of a clock driven program to hog the CPU, > by not getting charged for its time? > > -- danj@3skel.com Dan Janowski Triskelion Systems, Inc. Bronx, NY 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?Pine.BSF.3.96.980527161836.7655A-100000>