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

On Wednesday 16 May 2007, Pete Zaitcev wrote:
> On Wed, 16 May 2007 07:41:26 -0700, David Brownell <[email protected]> wrote:
> 
> > > in that when you have  
> > > pre-allocated all buffers and all USB host controller descriptors, you will 
> > > never get in the situation of not being able to allocate transfer descriptors 
> > > on the fly, like done on Linux.
> > 
> > That's not a failure mode that's been often observed on Linux.  (Never,
> > in my own experience... which I admit has not focussed on that particular
> > type of stress load.)  So it's hard to argue that it should motivate a
> > redesign of core APIs.
> 
> 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).


> However, the usb-storage worker thread can get stuck sleeping for
> allocations.

Might be good to look at removing that worker thread sometime.


> We try to deal with it by using GFP_NOIO carefuly, but 
> this is a palliative. I continue to hear from my users with systems
> locking up when they mount ext3 on winchesters in USB enclosures
> and use a simple cp. Switching from usb-storage to ub fixes the
> issue (which is why we continue to ship it). It's not a commonplace
> concern, but it persists. Sometimes it involves scsi_eh_0.

SCSI EH causes lots of strangeness.  :(


 
> 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.

- 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