Re: patch to shift memory allocations to usb_alloc_urb()

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.

> > 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.
> 
> It speeds up execution in real interrupts, which is good. 

I don't buy that.  Leaving interrupts disabled 90% of the time would
also speed up execution.  But it would ruin latency.

> Completion handlers might be called in a bottom half, but this
> is a rather intrusive change.

We don't need bottom halves.  Just remove the guarantee that interrupts
will be disabled.

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.

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