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/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
