On Monday 02 July 2007, Alan Stern wrote: > 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.
Same number of cycles yes, but more of them in IRQ context. No big deal AFAICT. > The total number of interrupts would depend on the HCD. Right now OHCI > is probably the worst case. Worst??? No, I'd say it's intermediate between UHCI (lots of IRQs) and EHCI (can have virtually none). > Dave says it can defer interrupts up to 7 URBs, Seven frames ... call it 8 KB and you won't be far off. > 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.) It'd be an IRQ every 7+N msec, where N is the time for one URB; if you assume that's one page, every 10 msec is sot of right. It wouldn't be 27 msec ... the biggest TD would hold 8 KBytes, closer to 15 msec total (7+N). > 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). Very true. > 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. Except for RT support? :) - 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
