Am Samstag, 9. Juni 2007 schrieb Pete Zaitcev:
> There's something you said in this thread which I would like to address.
> 
> > > So, you add 24 bytes to all URBs, which are... not very thin, to be sure.
> > > Last time I counted they were 152 bytes apiece. Still, a 15% increase.
> > > I know you're a good algorithmist, are you sure you don't have any ideas?
> > 
> > I figured the URB will end up in the same buckets for SLAB anyway due to
> > granularity.
> 
> This is true, except for legacy cases (such as ub), where URBs are
> embedded into other objects. This relies on them not being ISO and
> thus being embeddable. But majority is allocated dynamically and all
> of them will be eventually. So, what do you think about moving the
> ISO descriptors out of line, and then allocating URBs out of a slab?
> Such a move would save tons on external fragmentation, enough for
> anchors and more.

I consider that premature. Currently we are allocating the structures
private to the HCDs in usb_submit_urb(). That's wrong. Changing that
is incompatible with allocating all URBs from the same slab. It would have
to be specific to the HCD or even several pools per HCD.

> > Why do you care that much about the size of struct urb? There are a few
> > hundred of these structures at most at any given time. I think we gain more
> > in memory usage if we make using URBs easier, shrinking drivers' code.
> 
> Firstly, we certainly are reasoning without data here. Your hunch that
> we'll win anything in driver code is not any better substantiated than

Marcel is rewriting hci_usb. We'll learn from that.

> my hunch that URBs are too big and cause memory pressure in unfortunate
> moments (otherwise, why does usb-storage continue to lock up with
> write throttling issues, but ub works in same tests).

Why would the size of the URB matter? If we overflow the slab bucket, at
least a page will be allocated in any case.

> So, another reason why I like the slab is because it tells us how many
> are around.

True, but also available with an atomic counter exported through sysfs,
if you need it for debugging.

        Regards
                Oliver

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