Re: patch to shift memory allocations to usb_alloc_urb()

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel