Re: patch to shift memory allocations to usb_alloc_urb()

On Monday 02 July 2007, Oliver Neukum wrote:
> Am Montag, 2. Juli 2007 schrieb Alan Stern:
> > 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.
> 
> 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 winning strategy.

And if you don't have the memory to spend, then you spend the IRQ.
No worries, it all works fine.

- 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