On Monday 02 July 2007, Alan Stern wrote:
> 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.

Currently the number of IRQs per transfer is highly variable, and it
depends on what you mean by "transfer".  Worst case, let's assume it
means "scatterlist".

For EHCI, it's quite realistic to expect a single IRQ.

For OHCI, an IRQ every 10-15 msec is realistic.

Other host controllers can be all over the map, but in my own
observation most of them don't do even as well as OHCI.


> 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.

Change that only with extreme care.  :)

- 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

Reply via email to