Re: What to do with all of the USB UHCI drivers in the kernel ?

["Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>]

At 10:06 PM 5/21/2002 -0700, Greg KH wrote:
> > On a side note. Why are URBs still not SLABified ?
> > Drivers still have those silly urb pools and stuff. I thought you guys 
> were
> > gonna fix that.
>
>It hasn't been proven that it's really needed.  95% of the current
>drivers create their urbs when the device is plugged in, and then free
>them when they are removed.  Making that kind of allocation into a slab
>is a bit silly :)
Well, I'm claiming that those drivers are wrong ;)
It makes sense to pre-allocate intr in, iso and bulk in URB. But (imo) it 
doesn't make much sense
to pre-allocate ctrl and bulk out. For example one might never send stuff 
out of USB serial port,
because it used only for logging or something, ut write_urb will always be 
allocated. Same
goes for ctrl, one sends ctrl requests only once in a while but URB is 
always allocated.

Also as Dave pointed out kmalloc is already slabified anyway. And as I 
mentioned kmalloc
has fixed size slabs and therefor will waste some memory.

>Now if more drivers start doing fun stuff like the visor.c driver does
>in the 2.5 tree, then it might make more sense to create a URB specific
>slab.
Some drivers are still maintaining bulk URB pools which is just unnecessary 
code and mem waste.
They should allocate/free bulk urbs on demand.
visor, usbnet, hci_usb and some other driver allocate URB on demand.

I guess the reason for having driver specific URB pools is because 
usb_alloc_urb (using kmalloc) was
slow. Now if it's replaced with slab cache it's no longer the case. So 
drivers should not pre-allocate
stuff unnecessary.

It definitely doesn't hurt to have URB specific cache. You get better stats 
(like URB slab utilization, etc).
You could chose to do slab poisoning and debug URB allocations and stuff. 
You could use slab constructor
to pre-initialize some URB fields.

Max