Re: patch to shift memory allocations to usb_alloc_urb()

On Saturday 30 June 2007, Alan Stern wrote:

> First, notice that pre-allocation is useless with one-shot URBs, since
> the resources would be allocated anyway as soon as the URB is
> submitted.  You gain an advantage only by avoiding having the resources
> deallocated when the URB completes, so that they can be reused when the
> URB is resubmitted.  (Or possibly when a different URB is submitted for
> the same endpoint.)  How will your changes affect deallocation?

That's not entirely true.  The issue you're overlooking is that more
of the "pre" allocation can be done GFP_KERNEL ... when it's done in
the HCD submit "fast" path, it probably uses GFP_ATOMIC.

Of course that presumes that the length of time that spinlock is held
would be performance-critical, or that the allocation hits a memory
shortage so that time-shifting the allocation could avoid an -ENOMEM.


> Another thing worth noticing is that with reusable URBs, at allocation
> time you might not know the transfer lengths you will need.  Drivers 
> would have to guess at the maximum requirement and then live with that 
> guess.

Rather than giving up on the existing allocate-on-demand mechanisms,
I'd rather view any such guesses as just hints ... so that when drivers
don't guess right, it's no more of an error than it is today.

- Dave


> Finally, don't forget the advantages of avoiding preallocation and 
> keeping resources in a pool, available for multiple uses.
> 
> 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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel