From owner-freebsd-hardware  Tue Apr  2 12:17:37 1996
Return-Path: owner-hardware
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA22885
          for hardware-outgoing; Tue, 2 Apr 1996 12:17:37 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA22880
          Tue, 2 Apr 1996 12:17:33 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA16910; Tue, 2 Apr 1996 13:11:45 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199604022011.NAA16910@phaeton.artisoft.com>
Subject: Re: Hacked kernel with option to disable "green" mode
To: bde@zeta.org.au (Bruce Evans)
Date: Tue, 2 Apr 1996 13:11:45 -0700 (MST)
Cc: Brett_Glass@ccgate.infoworld.com, terry@lambert.org,
        freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org
In-Reply-To: <199604021358.XAA26252@godzilla.zeta.org.au> from "Bruce Evans" at Apr 2, 96 11:58:46 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hardware@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >> 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.