On Mon, 2 Jul 2007, Oliver Neukum wrote: > > I don't think so. For one thing, we'd be allocating fewer URBs. For > > another, the total number of submissions would be the same; they would > > just be spread out in time instead of all at once. > > But the number of interrupts would grow. The ideal number of interrupts > per transfer is 1. If you can avoid using more by using a bit more > memory, is a wiÅning strategy.
Currently the number of interrupts per transfer is larger than 1. Of course we can change that, but should we? On small systems, saving a little CPU time by using a lot more memory is not a win. > > Actually, the best way to approach this would be to relax the guarantee > > that completion routines are called with interrupts disabled. There's > > no real reason for that guarantee; it's just an historical remnant. > > It speeds up execution in real interrupts, which is good. I don't buy that. Leaving interrupts disabled 90% of the time would also speed up execution. But it would ruin latency. > Completion handlers might be called in a bottom half, but this > is a rather intrusive change. We don't need bottom halves. Just remove the guarantee that interrupts will be disabled. And BTW, it isn't necessarily true that IRQs are disabled during a real interrupt. Those sharing the same IRQ line are, yes, but others don't need to be. Our HCDs shouldn't need to set IRQF_DISABLED. Alan Stern ------------------------------------------------------------------------- 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
