On Fri, Dec 20, 2013 at 09:26:35AM -0000, David Laight wrote: > > From: David Cohen > > On Wed, Dec 18, 2013 at 11:24:47AM -0000, David Laight wrote: > > > This saves a kzalloc() call on every transfer and some memory > > > indirections. > > > > > > The only possible downside is for isochronous tranfers with 64 td > > > when the allocate is 8+4096 bytes (on 64bit systems) so requires > > > an additional page. > > > > If you take this to embedded world there could be a bad side effect too. > > The free memory isn't abundant and the fragmentation may make a bigger > > kmalloc() to cost more than 2 smaller ones. > > The effect of this change is really to remove the first allocation and > add 8 bytes (or maybe a pointer) to the start of the second one. > So it is extremely unlikely to fail when the old code would work. Currently struct urb_priv has a dynamic array of pointers to struct xhci_td. You're replacing the pointer by structs itself. Now, instead of 2 kmallocs() (1 for urb_priv and another for size * xhci_td) we've 1 kmalloc() with urb_priv + size * xhci_td. The remaining kmalloc() is size * (sizeof(struct xhci_td) - sizeof(struct xhci *)) bigger. I don't know what's the regular value of 'size', but even if size=1 new kmalloc() extra size is already bigger than 8 bytes. > > It would, of course, be better to allocate a parallel 'software' ring > containing the required extra information and completely remove the > additional allocate/free on every USB request. Can't argue on that. I'm still new to USB subsystem. > > David You've got a nice name :P Br, David Cohen > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
