Date: Thu, 3 Jan 2002 16:35:40 -0500 (EST) From: Mike Silbersack <silby@silby.com> To: Bruce Evans <bde@zeta.org.au> Cc: <freebsd-arch@FreeBSD.ORG> Subject: Re: DELAY accuracy Re: cvs commit: src/sys/dev/usb uhci.c Message-ID: <Pine.BSF.4.30.0201031624120.45843-100000@niwun.pair.com> In-Reply-To: <20020103194429.T15755-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Jan 2002, Bruce Evans wrote: > On Thu, 3 Jan 2002, Mike Silbersack wrote: > > > This seems irrelevant for calls of 100 or 1000, but > > changes timing quite a bit on calls between 1 and 10. So, it looks like > > rewriting DELAY so that it spin-waits on the TSC for delays of less than > > 100 might be useful. Maybe when I get some time... > > Sorry, this wouldn't be useful. As for sleep(3), system activity may > lengthen the delay by an indeterminate amount, unless you disable > interrupts, which would be bad. Slow machines may take longer than 1 > usec just to call DELAY(). Code should be written to not depend on > DELAY() being very accurate. OTOH, the i386 DELAY() could be written > better using microuptime(undoc). It would then be much simpler (except > possibly for complications to make it work at boot time), and more > accurate (except for small intervals on slow machines). > > Bruce Yeah, that does sound like a nice way to get more accuracy. I think that the boot-time considerations could be worked around by polling microuptime only if ticks > hz and using the old routine otherwise. I'm not actually concerned about DELAY() calls being accurate for the sake of the device drivers using such calls, but rather for the sake of rest of the OS; if a call to DELAY(1) in some commonly called interrupt handler is really taking 8us, that's 7us of extra interrupt latency that we could save. As for the users of large DELAY values (1000 or greater), I wonder if more drastic measures should be taken, such as changing such calls to use tsleep / timeout. It seems like a bad idea to stop the kernel for such periods of time. (Most of these usages seem to be used during device startup and error handling cases. While startup probably occurs only once, I could see how one device driver delaying for a long period of time due to an underrun/overrun could cause another device to do the same.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.4.30.0201031624120.45843-100000>