MTX_DEF versus MTX_SPIN

[John Baldwin]

On Wednesday, November 03, 2010 1:04:13 pm mdf at freebsd.org wrote:
> On Wed, Nov 3, 2010 at 9:42 AM, Andriy Gapon <avg at icyb.net.ua> wrote:
> > on 03/11/2010 18:27 mdf at FreeBSD.org said the following:
> >> It's not clear to me from the man pages (perhaps I didn't look at the
> >> right one?) in which environments I need a spinlock.  For example, I
> >> wouldn't think it's safe to use a MTX_DEF in a hard interrupt handler
> >> (i.e one that was registered with BUS_SETUP_INTR), but I see some code
> >> lying around here that does it and nothing I'm aware of has broken.
> >
> > Such a handler runs in an interrupt thread.
> > The "harder" interrupt handler is called interrupt filter in FreeBSD terminology.
> >  I think that it was formerly known as fast interrupt.
> 
> So a MTX_DEF is okay in that environment?

Yes.  In fact, the reason to have threads for interrupt handlers is to allow
interrupt handlers to use non-spin locks that block when the lock is held.

MTX_SPIN locks are generally not needed in device drivers.  The only reason a
driver would use one is if it used a filter handler which does not run in a
threaded context.

> What would "best practices" be considered for what code should be run
> in the interrupt handler versus a soft interrupt?  In this case the
> kinds of things we have to do at some level of interrupt are:
> 
>  - handle a heartbeat interrupt from firmware a few times a second
>  - get a DMA completion interrupt (completely handling this requires
> calling biodone on all the associated bios)
>  - receive an ECC interrupt (this requires reading registers off the
> card for details)
> 
> At the moment we're on stable/7, but we will be migrating the code
> base to something more recent in another year or so, if that affects
> the answer.

I suspect all of these are fine to handle in a regular interrupt handler.
If you need to run a task that needs to block on a condition (e.g. cv_*wait*()
or *sleep()), then you probably want to use a task to deter that to a
taskqueue.  At this point taskqueue's are probably the cloest thing FreeBSD
really has to a true software interrupt.  FreeBSD does have software interrupts
still, but the taskqueue API is actually easier to work with for device
drivers.

> Is there any documentation on best practices for writing a FreeBSD driver?

Not really. :-/

-- 
John Baldwin