Am Freitag, 15. April 2005 17:13 schrieb Alan Stern:
> On Wed, 13 Apr 2005, David Brownell wrote:
>
> > > That was the main motivation, although I'd had this in the back of my
> > > mind
> > > for a long time. Yes, it would be nice to see some real numbers for
> > > those
> > > latencies. I suppose I could add some high-precision timer stuff to the
> > > driver, to see just how much time actually is spent with interrupts
> > > disabled...
> >
> > I've deferred doing HCD performance work, on the grounds that usbcore
> > has -- until relatively recently! -- not been correct enough to trust.
> >
> > Over the last year, I think most of those correctness issues have
> > been getting resolved. Which means that maybe it's finally time to
> > do some performance work...
>
> Here are the results of a quick test. I attached a flash storage device
> and measured the times spent with the spinlock held and interrupts
> disabled while doing
>
> dd if=/dev/sda bs=1M count=16 of=/dev/null
>
> The two main places where the driver disables interrupts for long periods
> are in the enqueue routine and the IRQ handler. The results varied
> somewhat from run to run but they were all in the same ballpark. The
> tables below show the number of events of each sort and their average and
> maximum times. All times are in microseconds.
>
> On a Pentium IV running at 1.8 GHz:
>
> Count Avg Max
> Enqueue: 1148 140 706
> IRQ: 2175 101 746
>
> On a Pentium II running at 350 MHz:
>
> Count Avg Max
> Enqueue: 1227 511 3000
> IRQ: 2769 248 1935
>
> In my opinion, 740 us is a long time to leave interrupts disabled and 3 ms
> is unacceptable. People working on real-time systems often prefer to have
> interrupt latencies in the vicinity of 10-50 us.
>
> It's true that other changes I have planned for the driver will reduce
> these values, although it's impossible to predict by how much. However I
> think this gives a pretty good indication that splitting the driver into a
> top- and bottom-half is worth considering.
Why? The worst case is in enqueue. Enqueing is not always interrupt
driven. IMHO the best way to reduce times is to move all memory
allocations into urb allocation.
Regards
Oliver
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
