On Mon, 2 Jul 2007, Oliver Neukum wrote: > Am Montag, 2. Juli 2007 schrieb Alan Stern: > > > As noted above, for full speed devices we could get similar throughput > > > with slightly more clever implementation of scatterlist handling. If > > > the HCD has good hardware support for queueing, and the system has fair > > > IRQ latency, recycling as few as five URBs might give similar throughput > > > to the current "URB per element" approach. > > > > I think we definitely should do this. For high speed the advantages > > aren't so great, since the amount of data needed to fill the pipeline > > is about the same as the default max transfer size anyway. > > Doesn't this boil down to using CPU cycles to save memory? > Even worse, many of these cycles would be used in interrupt context.
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. The total number of interrupts would depend on the HCD. Right now OHCI is probably the worst case. Dave says it can defer interrupts up to 7 URBs, so if you submit up to 16 URBs at a time then you would gain little or no overhead. (Note that at full speed, it takes almost 27 ms to transfer eight 4-KB URBs. I think getting an IRQ even every 10 ms would be okay.) As for the number of cycles in interrupt context... Much of the work involved in submitting an URB takes place with interrupts disabled anyhow. And for that matter, the s-g library already disables interrupts while submitting each URB (although it re-enables them in between). 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. But drivers do rely on it (the handlers call spin_lock rather than spin_lock_irqsave, for example), so changing it would require a fair amount of work. Worthwhile, in my opinion, but I don't want to do it. 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
