On Wed, Feb 21, 2007 at 10:51:03PM +0000, Andrew Doran wrote:
quoted text
> Hi Jason,
>=20
> On Wed, Feb 21, 2007 at 10:01:44AM -0800, Jason Thorpe wrote:
>=20
> > 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.
>=20
> 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.
>=20
> For the general case, I don't agree though. On recent processors with long
> instruction pipelines, serializing control operations are really expensiv=
e.
quoted text
> x86 chips from 5 years ago are faster in this regard than the current Int=
el
quoted text
> 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=
ce
quoted text
> actually has a justifiable benefit, So I have been trying to eliminate th=
ese
quoted text
> 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.
>=20
> 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=
=20
can turn it into something that's "about as good" then I think you will=20
just get a green light. :-)

Take care,

Bill