On Thu, Jul 05, 2007 at 04:57:53PM -0400, Alan Stern wrote: > On Thu, 5 Jul 2007, Matthew Dharm wrote: > > > On Mon, Jul 02, 2007 at 09:15:03AM +0200, Oliver Neukum wrote: > > > Am Montag, 2. Juli 2007 schrieb Alan Stern: > > > > If you look at usbmon logs of real usb-storage data transfers you'll > > > > see that multi-page sg elements occur quite frequently. (Of course, > > > > that doesn't prevent us from transferring only one page per URB.) > > > > > > OK, but the storage driver allocates the URBs on the fly. If we change > > > that to preallocation we need to have enough URBs for the worst case. > > > > Of course, in the storage case we control the worst-case. By adjusting the > > parameter which controls how long a sg list the SCSI core will send us, we > > can effectively limit the worst-case number of URBs needed. > > But we don't control max_sectors, so we can't effectively limit the > total transfer size. > > While I agree that it would be nice to preallocate enough URBs and > memory that only one IRQ would be needed, I don't see anything wrong > with preallocating a reasonably large amount and re-using it as needed. > So we might get 3 or 4 times as many IRQs for particularly large > transfers; that doesn't seem too bad. It's a justifiable time-space > tradeoff. > > A reasonably large amount might be enough for a 32 KB transfer at full > speed or a 120 KB transfer (the default maximum) at high speed. Or we > might want to take into account the actual storage requirements of the > HCDs; UHCI is much the worst in that regard.
After digging out from all the vacation e-mail, I'm relatively convinced
that just about anything discussed would be better than what we have now.
If that's a "fallback" to a single pre-allocated URB, or a pre-allocated
small pool of URBs, or a pre-allocated large pool of URBs, it's all better.
Right now, we just choke in OOM situations. And that's just horrific.
I'm guessing that the best thing to do now would be to implement the
"fallback to one URB at a time" algorithm in a -ENOMEM situation. That's
going to provide awful performance in OOM conditions, but at least it won't
crash.
If it's done with some forward-looking to a "pool" approach (i.e. a pool of
size = 1), then playing with pools of size 1, 5, or 500 would be something
we could experiment with.
Once we have something like that in place, it will probably be easier to
look at the space/time tradeoffs in more real terms. Eventually, that
tradeoff will probably be an adjustable constant (parameter?) which will be
relatively large for desktop/server users, and easily turned to something
small for embedded systems.
Matt
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
But where are the THEMES?! How do you expect me to use an OS without
themes?!
-- Stef
User Friendly, 10/9/1998
pgpC65rTqnkh5.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
