On Thu, Feb 22, 2007 at 12:59:23AM +0100, haad wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Bill Studenmund wrote:
> > 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  
> >>> simple and avoid magic, it could be very fast, which would help  
> >>> 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 expensive.
> >> x86 chips from 5 years ago are faster in this regard than the current Intel
> >> 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 existence
> >> actually has a justifiable benefit, So I have been trying to eliminate these
> >> 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? 
> > 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 
> > just get a green light. :-)
> > 
> > Take care,
> > 
> > Bill
> AFAIK solaris use the kernel threads for interrupts we can look at the open
> solaris sources how the solved this issue with SPARC CPU architecture.

As a rule, I think we're better off not looking at CDDL/GPL licensed code
when implementing similar functionality. If you find some intractable
problem or you want to see what another system does when it comes to
standards, it can be handy to get hints. Otherwise it seems to me like
asking for copyright problems.

Cheers,
Andrew