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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
