Subject: Re: 1.6.2 kernel: ex driver sometimes can't allocate
To: None <tech-kern@NetBSD.org>
From: Chapman Flack <email@example.com>
Date: 09/21/2004 16:54:46
> > 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
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?