Re: New USB stack on FreeBSD w/Linux emulation layer coming

On Wednesday 16 May 2007, Alan Stern wrote:
> On Wed, 16 May 2007, David Brownell wrote:
> 
> > > I have never, ever, seen USB stack deplete the atomic pool completely
> > > either, if this is what you are talking about. So, you're quite right
> > > about that.
> > 
> > I was referring to the dma_pool allocations ... those don't need
> > to be atomic.  OHCI or EHCI tend to allocate a page or so for each
> > type of descriptor seen by the hardware, and usually won't need
> > more than that.  UHCI uses more pages; TD-per-packet requirements
> > from the hardware, ISTR (instead of multiple-pages-per-TD).
> 
> If dma_pool allocation isn't atomic, does that mean it could block for 
> I/O?  If yes, then it doesn't belong on the usb-storage I/O path.

dma_pool_alloc() takes gfp_flags, and (looking at the code)
tests only for __GFP_WAIT.  So if you don't pass that flag,
it won't wait...


> > > I have come to think that ub does not dramatically alter the pressure
> > > on the atomic pool. It allocates the same QHs and TDs. It's the thread
> > > which is the main problem, because it allows for interesting scenarios
> > > of deadlocks between kswapd, scsi_eh_0, and usb-storage helper.
> > > I am thinking about taking the ub concept and integrating it into
> > > usb-storage as some kind of "threadless" option. If only I could
> > > get rid of the SCSI error handling...
> > 
> > Agreed, all those threads make things complex ... probably more so than
> > is really needed.
> 
> I wonder...  ub does away with thread complexity by using a complex 
> state machine.  Ultimately the complexity lies in the USB mass-storage 
> protocol and in error handling; we can't get away from it no matter how 
> we try.

Tradeoffs, tradeoffs... yeah, proponents of threads always
like to point out the seeming (micro-) simplicity.  It's not
clear to me that any resulting macro-complexity is a win in
all cases.  Sometimes it's clearly not.  In this case, I
said "probably" because the macro-complexity of USB-storage
gets multiplied by the macro-complexity of SCSI.  (I think!)
Error paths are where the rubber meets the road...

Sometimes you can almost understand why people would choose to
live in a fantasy-based world, not the reality-based one.
Of course, folk making that choice have no business making
decisions affecting the real world (including kernel code).  :)

- Dave





-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel