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