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