Subject: Re: Interrupt, interrupt threads, continuations, and kernel lwps
To: Matt Thomas <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 02/21/2007 10:01:44
On Feb 21, 2007, at 12:08 AM, Matt Thomas wrote:
> After a great of pondering, I've concluded that interrupt threads
> are an extremely bad idea.
Matt and I discussed this at length over lunch yesterday, and I am in
full agreement with him on this.
The way I see it, interrupt threads are an attempt at solving the
synchronization problem from the wrong direction. Instead, I think
the right approach is to fully split every driver into a "top
half" (runs with thread context, possibly as a high-priority kernel
thread) and "bottom half" (runs in interrupt context).
Furthermore, I believe that the bottom half should manipulate state
that is local only to the instance of the driver associated with the
device that is interrupting (and have that state be spin-mutex
This approach would have a few advantages:
1- Simplicity. Interrupt dispatch would be largely as it is today.
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.
3- Portability. Because the low-level interrupt dispatch would work
basically like it does today, we know it will work on all of our
extant platforms. I think there are some particularly nasty "gotchas"
with interrupt-dispatch-as-continuation-or-thread that can be hard to
fix on platforms like VAX (especially) or even SPARC and m68k.
4- Consistency. We already have this sort of model "sort of" today;
consider serial drivers that have hard-interrupt handlers that run at
extremely high priority to read data into a local ring buffer and then
schedule a soft interrupt to do the TTY processing. What I'm looking
for here is to formalize this for EVERY kind of device. This will
make it easier to write drivers for NetBSD. We could even provide
some API to help people write drivers that conform to the model.