Re: [Patch] Increase USBFS Bulk Transfer size

[Alan Stern]

On Mon, 7 Nov 2011, Sarah Sharp wrote:

> > > Yeah, the choice is not obvious and we're probably going to get it
> > > wrong, but as Tim said, he does need ~600MB in flight at once, so I knew
> > > 16MB was too small.  I guess the question really should be not "What is
> > > the smallest limit we need?" but "When will the system start breaking
> > > down due to memory pressure?" and set the limit somewhere pretty close
> > > to there.
> > 
> > It might not be so easy to identify that value.  I wouldn't know how to
> > do it.
> 
> I wouldn't know how to test it either, and I suspect it would be
> system-specific.  Are you at least OK with setting the limit to 600MB so
> that Tim's userspace driver will work by default?  I think we still need
> the modparam for the usb core to set the limit as well.

I don't know; 600 MB sounds kind of high for some systems.  It's
entirely possible to run Linux on a machine with < 1 GB of RAM.  I'd
feel a lot safer making the default value small, like 16 MB, and asking
Tim's clients to increase it.

> > Again, I don't know.  Those subsystems are a lot more complicated than
> > usbfs, and they probably have arrangements to allocate intermediate
> > buffers a piece at a time.  We could do something like that, but the
> > end result would be the same as our current limit on URB sizes -- the
> > only difference being that transfers would be split into multiple URBs
> > by the usbfs driver instead of by the user program.
> 
> Or splitting the transfer into multiple scatter-gather list entries,
> right?

Not really, because the problem is to avoid loading all the buffers
into kernel space at the same time.  That means using multiple URBs --
although each URB could use SG to handle more than 16 KB at once.

>  There's no need to submit multiple URBs if you can just use
> sglists instead.  If the host can't handle sglists, the core can just
> split it up into multiple URBs.  I'd like to push the biggest data
> chucks we can as far down in the stack as possible to avoid performance
> hits from completing many URBs.  But that's a separate issue...

Right.  For example, usbfs could support an iov sort of interface.  
That would translate naturally into an SG list.

> > In fact, it's not all that easy for a program to generate many I/O 
> > requests concurrently.  The old async I/O mechanism is one way, and you 
> > spent a lot of time working on it.  Do you remember if it had any 
> > limits?
> 
> I haven't looked at that in about four years, so if it did I don't
> remember it.  Maybe someone from the aio list knows?

One point that hasn't been emphasized very strongly (although it was
mentioned once) is that our _current_ kernel allows programs to submit
many USB transfers and thus eat up all available kernel memory.  That
definitely could be considered a bug.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/