--pAwQNkOnpTn9IO2O
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 16, 2006 at 10:07:14AM -0800, Garrett D'Amore wrote:
> Eric Haszlakiewicz wrote:
> > On Thu, Mar 16, 2006 at 11:49:47AM -0500, Steven M. Bellovin wrote:
> >> On Thu, 16 Mar 2006 09:16:57 -0500 (EST), Matthew Orgass
> >> <darkstar@city-net.com> wrote:
> >>> On 2006-03-16 hselasky@c2i.net wrote:
> >> The question is this: what do you do in the interrupt handler or
> >> timeout if you can't get the mutex?  You can't sleep; there's no
> >> process context.

Answer to Steve: you have to spin. For now.

> > 	I think you have to spin.  Since the splfoo() in non-interrupt code
> > ensures that the current processor can't have been in the middle of the
> > mutex protected code, you know that it must be some other processor that
> > holds the lock.  Eventually, that processor will release the mutex and
> > the interrupt handler will get it.  Of course, if the non-interrupt code
> > holds that mutex for long the interrupt latency will suck.
> >
> > 	I don't know what you'd do in the callout.  Maybe re-register the
> > callout and try again later?
>=20
> I think this is a deficiency in NetBSD's design right now.  If we have
> prioritized interrupts, and the interrupt handler runs at a SPL lower
> than the clock, then it should be possible to sleep.

Kinda. That's hard to get right.

Right now our interrupt handling is still under biglock. So right now this=
=20
isn't an issue, as you have to wait for the other CPU to release it.

I think we're going to try for spinlocking first. It's a good intermediate=
=20
step, and can let us have multiple CPUs in kernel code simultaneously.

And once we get spinlocks working, migrating to mutexes isn't too hard.

> Granted, I suspect not all platforms have reasonably prioritized
> interrupts where the clock interrupt gets serviced at a priority higher
> than device interrupts.

See a post from me back in I think it was December. It's worse than that.=
=20
You can NOT list a common hierarchy of spl levels for MI code. Sometimes=20
spltty < splnet, sometimes spltty > splnet....

> However, for the platforms I am familiar with (PCs, MIPS, SPARC), the
> clock does get prioritized treatment over at least *most* interrupts.=20
> (The exceptions I know about are serial ports and PCMCIA status change
> interrupts.)
>=20
> Another OS with which I'm familiar calls this difference out by having a
> way to identify an interrupt as being "high priority" or not.  You can
> do things like sleep with a lock initialized with a cookie corresponding
> to a regular priority interrupt.  You cannot sleep with such a lock if
> the interrupt is a high priority interrupt.

I believe that said OS has a lot more $$, people, and history thrown at=20
this problem. We are where we are now.

> This other OS also runs interrupt handlers on their own threads, so that
> sleeping doesn't prevent other interrupts from being serviced.  :-)=20
> This probably has all kinds of performance implications for devices that
> require low interrupt latency.  (Usually com ports, which is why on the
> hardware this os runs on, com ports are generally a high-priority
> interrupt.)   There is also stuff in this OS to handle priority
> inversion, so that a regular thread holding such a lock gets CPU time so
> that the interrupt handler doesn't have to wait too long.
>=20
> Device drivers are responsible for not sleeping if they are holding a
> high-priority lock.  (This is easily tested for by adding an assertion
> test against the SPL in the sleep routines.)

As above, I think the idea is to go spinlocks first. But I don't think=20
anyone is fundamentally opposed to doing this better.

Take care,

Bill

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

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

iD8DBQFEGe9QWz+3JHUci9cRAqQdAJsEw+G3aNpZKj+sVlsmgjwfCr8BDQCfbpTA
vUmwnFxNIfxhmAMuxgypYgU=
=cbK3
-----END PGP SIGNATURE-----

--pAwQNkOnpTn9IO2O--