On Wed, 16 May 2007, Pete Zaitcev wrote:

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

It's also true for bulk-only; the same URB and buffer get used for the
IN and the OUT endpoints (CSW and CDB).  Yes, we could dealias them if 
necessary.

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

With a large potential waste of memory!  UHCI is so inefficient that
the TDs use up almost as much memory as the data to be transferred
(within a factor of 2).  Do we really want to keep those things around
when they're not being used?

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

At the cost of wasting the memory for the URBs and the TDs when they 
aren't needed.  And this wastage would have to be multiplied by the 
number of the USB mass-storage devices attached to the system.

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

It's possible that we have moved too far in one direction.  Even though 
you might not want to preallocate things all the time, it would be nice 
if you had the ability to do it when you wanted to.  But of course, it 
would add code and debugging complexity.

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

Reply via email to