Re: Interrupt, interrupt threads, continuations, and kernel lwps

Bill Studenmund <wrstudennetbsd.org> writes:

> The design we're talking about is very strongly
inspired by the
> Solaris model.

As I understand it, that model is highly optimized for
bus-based
interrupt controllers and not particularly suitable for
scaling to
large numbers of independent interrupt sources per
processor.

> Given that the desire is to run the interrupt
"thread" by borrowing the 
> context of the interrupted thread, we will have mostly
the same thing as 
> now. It took me a while to figure this out.

It's the part that varies from "mostly" that
concerns me. If it turns
out that the assumption of very low lock contention is
wrong, the
cascading and convoying effect that results from contention
will be
very difficult to bound in soft real time systems.

>> It may be more work to get there, but it's an
incremental change from
>> the current NetBSD model, and drivers could be
converted as needed,
>> rather than trying to get everything right in one
fell swoop.
>
> The paragraph above actually is one selling point of
what Andy's
> suggested so far.  For
architectures (platforms) with a PIC, my
> understanding is the x86 change should be a model that
can be
> cookie-cuttered around. There are issues with modal
architectures
> (ones with a separate interrupt stack), so we aren't
done yet. But
> we're getting there.

I think, as I said above, there are also issues with
non-bus-like
architectures.

> Oh, I like the idea of keeping the top/bottom split. I
don't want to
> be doing tons of work in an interrupt thread!

A wise man once told me that "if you're doing more work
in interrupt
context than you can comfortably code in assembler in an
afternoon,
you're doing too much work in interrupt context." ;)

On Thu, Feb 22, 2007 at 10:33:36PM -0800, Bucky Katz wrote:
> 
> A wise man once told me that "if you're doing more
work in interrupt
> context than you can comfortably code in assembler in
an afternoon,
> you're doing too much work in interrupt context."
;)

However you are going to have to execute the cpu cycles at
some point,
if the interrupt isn't going to schedule a process then you
probably
want to avoid the cost of the scheduling the deferred code.

Remembers the ISR code to drive a stepper motor graph
plotter under RSX/11M
(which expected the h/w ISR to just remove the IRQ and leave
the rest of
the code to some os work queue...)

	David

-- 
David Laight: davidl8s.co.uk