> From: 'David Cohen' > On Mon, Jan 06, 2014 at 09:26:20AM +0000, David Laight wrote: > > > From: David Cohen > > > On Fri, Dec 20, 2013 at 09:26:35AM -0000, David Laight wrote: > > > > > From: David Cohen > > > > 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. > > > > You misread the old code. > > The first malloc was for the header and 'n' pointers. > > The second malloc was for 'n' copies of the structure. > > That's exactly what I described but in a more complicated way :) > > The new kmalloc is going to be "n * sizeof(struct) - n * sizeof(pointer)" > bigger. I don't know what is the usual range of values for "n", but my > experience with android devices with non-abundant memory size is that > they are sensible to kmalloc > PAGE_SIZE. It is much easier to assume that we are keeping the second malloc are getting rid of the first one. The header is only one pointer. > Back to your patch description, you mention new kmalloc size may be > PAGE_SIZE + 8 bytes, which means kmalloc may have to find 2 consecutive > free pages. Of course it is not a big issue, but I don't see a reason to > unnecessarily change 2 kmalloc < PAGE_SIZE by one possibly > PAGE_SIZE. The values of 'n' are unknown. I doubt that the value that just exceeds a page happens any more often than those either side of it. David -- 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
