--rQ2U398070+RC21q
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,
>=20
> On Wed, Feb 21, 2007 at 12:08:36AM -0800, Matt Thomas wrote:
>=20
> > After a great of pondering, I've concluded that interrupt threads are =
=20
> > an extremely bad idea.
>=20
> 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=
=20
them.

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=
=20
exit the interrupt, you'll just reenter it. So you have to have interrupts=
=20
remain disabled until this interupt handling thread completes. That's not=
=20
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 =
=20
> > appropriate IPL), the handler will disable the cause of the =20
> > interrupt, optionally it may use a SPIN mutex to gain control over a =
=20
> > shared section, do something to the device, release the mutex, or it =
=20
> > 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).
>=20
> I gave this a lot of thought too. As a general solution, I really don't l=
ike
> it because it is unnecessarily expensive, both in terms of execution time
> and (perhaps more importantly) the effort involved in converting all of o=
ur
> 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=
ts:
> 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=
ain
> 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=
is,
> 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=
=20
software interrupt handling routine then comes along and does the heavy=20
lifting.

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,

Bill

--rQ2U398070+RC21q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFF3IZwWz+3JHUci9cRAjGMAJ4zcwKMEuVCxr4r0MQeOKj/kooP9ACdF9Nu
xX+8dPg3rcITaKeAKjJyM0g=
=Lryd
-----END PGP SIGNATURE-----

--rQ2U398070+RC21q--