> > is it fast enough to do within bus_dma_alloc( ...NOWAIT) ?  what are the
> > latency requirements there?
> 
> As bus_dma_alloc(...NOWAIT) can be used from an intr handler, another
> flag allowing this "extra effort" could be appropriate, so that device
> driver writers can disable it on latency-critical paths?

That's a possibility, but then it still leaves the possibility that some
necessary driver operation fails because only of what the userland happens
to be doing at the time, and that seems undesirable.  It seems to me a
design should consider several questions (and I don't know NetBSD kernel
well enough to guess at the answers) ...

o  under what spl's is it considered ok to call bus_dma_alloc()?

o  what worst-case latency is tolerable under the highest expected spl?

o  is unreserved-allocation-with-shuffling practical under those
   latency requirements?

o  is reserved-allocation-with-clean-page-invalidation practical under
   those latency requirements?

o  hmm, is bus_dma_alloc() commonly called from driver routines other
   than attach()?  Is this problem one that can only arise when attach()
   is called after the system has booted?  does that mean it can only
   be a problem for hot-pluggable drivers like cardbus and usb?  do all
   such drivers have kernel threads that manage them?  does that mean it's
   possible to do blocking alloc() in all those attach functions, and
   sidestep the latency questions?

-Chap