Re: [Patch] Increase USBFS Bulk Transfer size

Alan Stern
2011-11-08T01:44:28Z

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