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

On Wed, Feb 21, 2007 at 10:09:00AM +0000, Andrew Doran wrote:
> Hi Matt,
> On Wed, Feb 21, 2007 at 12:08:36AM -0800, Matt Thomas wrote:
> > After a great of pondering, I've concluded that interrupt threads are =
> > an extremely bad idea.
> Fair enough, but why so?

Funny, I was talking w/ Jason and Matt about this yesterday at Lunch.

There are two problems. Vax has both of them, and m68k has at least one of=

One problem is that some systems, like vax, are modal. There's a=20
difference running something in interrupt handling context and not. Matt=20
noted that the vax has separate interrupt stacks. So interrupt code is=20
more than just code running quickly (low latency) at high priority.

The other problem, which I know mac68k has too, is that you have to make=20
the hardware shut up as part of the interrupt handling. Otherwise once you=
exit the interrupt, you'll just reenter it. So you have to have interrupts=
remain disabled until this interupt handling thread completes. That's not=
what is in my mind as a result of this discussion so far.

> > I think that hard interrupts should simply invoke the handler (at the =
> > appropriate IPL), the handler will disable the cause of the =20
> > interrupt, optionally it may use a SPIN mutex to gain control over a =
> > shared section, do something to the device, release the mutex, or it =
> > may just schedule a continuation to run (either via software =20
> > interrupt or via a kernel lwp workqueue, the former can't sleep/=20
> > block, the latter can).
> I gave this a lot of thought too. As a general solution, I really don't l=
> it because it is unnecessarily expensive, both in terms of execution time
> and (perhaps more importantly) the effort involved in converting all of o=
> drivers to work this way. Conversely, the changes I have to handle
> interrupts using LWPs add 29 instructions to a typical interrupt chain on
> x86, to swap stack and curlwp. It works, and it's a solution that can just
> be "dropped in".

So how would this work on other architectures?

> To reiterate, there are two reasons I want to use LWPs to handle interrup=
> signficantly cheaper locking primitives on MP systems, and the ability to
> eliminate the nasty deadlocks associated with interrupts/MP and interrupt
> priority levels. The intent is *not* to rely heavily on blocking as the m=
> synchronization mechanism between the top and bottom halfs. That's why in
> the near term I want to preseve the SPL system for places where it really
> does matter. I did a lot of profiling to see where we would need to do th=
> and the network stack is once place.

I think a good model would be something like how the z8530tty driver works
but dusted off. There is a hard interrupt handler that reads the chip. On
receive, it stuffs characters into a ring buffer and then triggers a soft
interrupt. Transmit, it stuffs characters into the chip.

Either way, the hard interrupt handler is small and just does pseudodma. A=
software interrupt handling routine then comes along and does the heavy=20

I really like the idea of the latter routine being a thread & using=20
mutexes. The former, though, I think should remain a fast little routine.

Take care,


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

Version: GnuPG v1.4.3 (NetBSD)