Low perfomance when read from usb flash drive

[M. Warner Losh]

In message: <200903041001.37376.hselasky at c2i.net>
            Hans Petter Selasky <hselasky at c2i.net> writes:
: On Wednesday 04 March 2009, M. Warner Losh wrote:
: > In message: <200903040922.48163.hselasky at c2i.net>
: >
: >             Hans Petter Selasky <hselasky at c2i.net> writes:
: > : Hi Steve,
: > :
: > : On Tuesday 03 March 2009, Steve Calfee wrote:
: > : > > I think the reduced performance can be explained by a clamp on the
: > : > > interrupt rate around 1000 interrupts per second instead of 8000.
: > : > > Maybe someone has an explanation for this?
: > : > >
: > : > > The EHCI is being programmed to interrupt at 125us intervals, but
: > : > > there seems to be limits other places.
: > : > >
: > : > > It is possible to workaround this in the umass driver by doing the
: > : > > cmd + read in one operation.
: > : >
: > : > Hi Hans,
: > : >
: > : > I am looking at using FreeBSD in an embedded product. I have not
: > : > examined your ehci software, but I am aware of how Linux and other
: > : > OSes run the controller.
: > : >
: > : > Why are you taking an interrupt every uFrame SOF?
: > :
: > : If the transaction completes before 125us we take the interrupt before
: > : 125us. The problem is that the interrupt delay becomes critical to
: > : performance when the interrupt rate is close to the interrupt limitation.
: > :
: > : For example:
: > :
: > : Transferring 13Mbyte/sec at blocksize equal to 65536 bytes generates 600
: > : interrupts. Hence the Mass Storage state machine has three steps the
: > : throughput is computed like (600/3)*65536 bytes. If we on the average
: > : have to wait 0.5ms for an interrupt we loose throughput.
: >
: > Shouldn't you be using filters and such to make this less relevant?  A
: > filter runs on the order of 5us after the interrupt on fast machines,
: > and 20us on slower (400MHz) ones.  You can feed the pipeline better,
: > and handle higher interrupt rates...
: >
: 
: Yes, that's one possibility. It looks like there is some timing slightly out 
: of sync. I have an AMD box with the same symptoms. I will try to figure out 
: what is causing it.

Maybe there's just good, old-fashioned lock contention going on?  7.x
has more Giant use than 8.0 will, and in the past this has been a
source of problems.  Something else to check into.  Maybe enabling
lock profiling might yield some good data?

Warner