On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> It's worth pointing out that there already are drivers which > preallocate URBs and memory buffers and then share them among multiple > endpoints. One example is usb-storage. This is for CBI transport, right? Honestly, I forgot about that. But aren't control transfers short, just commands and replies? Their buffers can be dealiased, *if* need arises. > We have discussed in the past the notion of making URB allocation > per-bus. That would have less impact; not too many drivers share URBs > among different devices (although I think the Bluetooth driver does). > The advantage is that the allocation could then automatically > incorporate an HCD-private area; currently this has to be allocated > separately every time an URB is submitted. Right. Per-endpoint with a size limits also allows TDs to be preallocated. > > The requirement for massive on-the-fly allocations is a part of Linux > > stack that bothered me for a long time. This is especially annoying > > for block devices when pressure builds up in the VM, and dirty data > > has to be written out to a block storage device attached by USB. > > This is somewhat analogous to the problem which exists with NFS. > > I don't see how either of these scenarios would be affected. Whether > you do all the other allocations when the URB and its buffers are > allocated or you wait until the URB is submitted, the memory pressure > would still be just as bad. If URB, hcd_priv, and TDs are preallocated, the allocation happens when there's no pressure, and not when all of your memory is dirtied. It can also happen on a process context. > > I suppose we could do one last effort: > > - redefine usb_buffer_alloc to allow for endpoint argument > > - implement methods in HCDs to allocate and free QPs and xxx_priv > > - spell out in documentation very clearly that drivers should > > NOT use these facilities by default and only use them when > > memory pressure invokes these URBs > > > > This is something which, I think, only Greg Kroah can decide on doing > > or not doing. > > I am not in favor of such a large change. Yeah... I mentioned in my reply to David that I would like to explore more narrow approaches, like a threadless ub-like usb-storage. This won't help Hans in any way, though. -- Pete ------------------------------------------------------------------------- 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
