Date: Tue, 2 Apr 1996 13:11:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: Brett_Glass@ccgate.infoworld.com, terry@lambert.org, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Message-ID: <199604022011.NAA16910@phaeton.artisoft.com> In-Reply-To: <199604021358.XAA26252@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 11:58:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> This lets you replace recurrening events with rescheduling the > >> oneshot, and replace DELAY() with a one-shot scheduling. > > >This would certainly work. But the advantage of the timer is that it would > >be sharable; the one-shot wouldn't be. > > You haven't seen Terry's one-shot timers :-). Neither have I, but I > expect they would be shareable. E.g., if the next interrupt is > scheduled after 75 usec and something wants one after 22 usec, then the > timer would be reprogrammed to schedule the next interrupt after 22 usec > nsec and again later to schedule the original interrupt. Of course, it > might take 5-20 usec to reprogram the timer (20 usec on a 386/20) and > another 5-20 usec to switch contexts, not to mention 5-20 usec to accept > the interrupt and 5-20 usec to handle it, so one-shots are probably not > viable for such small timeouts. I think they will be viable for timeouts > a few hundred usec when the system becomes more real-time. See another > discussion about bugs that cause clock latencies of > 10000 usec. Reminds me of Bill Cosby playing the devil... "You haven't seen our bats". 8-). Bruce is right about the design. He's also right about the programming latency. He's also right about the clock latencies (which would have to be corrected by kicking the one-shot priority higher than everything but actual non-FIFO'ed I/O). Within the latency period, the timer is useful; outside it isn't. A DELAY(10) would not be replaced by a timer call, but a DELAY(200) would. > >In any event, how much would the scheduler and vm modules have to change > >-- if at all -- to allow unaffected processes to continue during swapper > >I/O? > > Not at all, I think. Large changes would probably be required to give > enough (if any) unaffected processes. Again, Bruce is right. Probably the largest change would be interrupt virtualization -- and if you've been watching the PCI and PCMCIA commits, this is real close: no major architectural changes required for most code, just some drivers. And they can be converted incrementally, it doesn't have to be wholesale. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604022011.NAA16910>