Subject: Re: Interrupt, interrupt threads, continuations, and kernel lwps
To: Andrew Doran <>
From: Bill Studenmund <>
List: tech-kern
Date: 02/21/2007 15:42:24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 21, 2007 at 10:51:03PM +0000, Andrew Doran wrote:
> Hi Jason,
> On Wed, Feb 21, 2007 at 10:01:44AM -0800, Jason Thorpe wrote:
> > 2- Speed.  Because the low-level interrupt dispatch code could be =20
> > simple and avoid magic, it could be very fast, which would help =20
> > devices that are particularly sensitive to interrupt latency.
> If you have a device that's particularly sensitive to interrupt latency,
> then the two level model is a good one, I agree completely. There is
> nothing to prevent that model from being used where it's a good fit.
> For the general case, I don't agree though. On recent processors with long
> instruction pipelines, serializing control operations are really expensiv=
> x86 chips from 5 years ago are faster in this regard than the current Int=
> offerings - in real time, not clock cycles. I'm keen to avoid that kind of
> "funneling" of work unless it's really neccessary - meaning, it's existen=
> actually has a justifiable benefit, So I have been trying to eliminate th=
> kinds of operations where they are unnecessary, e.g: during lock release,
> during splx(), during syscalls, in the locking scheme devised for the
> scheduler and so on.
> What I want to do will on x86 add 29 arithmetic instructions to the
> interrupt path (as of now). That's means in the common, non blocking case,
> it's ~free. I'd be pretty bummed if we undo some of that and the reasoning
> for doing so is to make the system a better fit for ~20 year old systems.

Ok, that sounds good. How do we make this work on SPARC, m68k, and VAX?=20
Right now, interrupts-as-threads sounds like a total loss for them. If we=
can turn it into something that's "about as good" then I think you will=20
just get a green light. :-)

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)