On Monday 02 July 2007, Alan Stern wrote: > 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.
Currently the number of IRQs per transfer is highly variable, and it depends on what you mean by "transfer". Worst case, let's assume it means "scatterlist". For EHCI, it's quite realistic to expect a single IRQ. For OHCI, an IRQ every 10-15 msec is realistic. Other host controllers can be all over the map, but in my own observation most of them don't do even as well as OHCI. > 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. Change that only with extreme care. :) - Dave ------------------------------------------------------------------------- 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
