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