Jacques Grove wrote:

Alan,

I've applied your patch, and I'm running various tests against the drive
right now, including some brutal iozone benchmarks.  It hasn't broken
yet, which is promising.

Funnily enough however, with your patch, the cpu overhead seems to be
higher than with just inserting the 250 us udelay before handling the
USB command (which I confirmed also worked after switching off all the
debugging). This is looking at the percentages of system (lower with
the udelay) and wait-for-io time (higher with the udelay), and the CPU
that the usb-storage thread consumes (much higher with your patch). However, this might just be a byproduct of how the CPU time is
recorded and accounted for?


Anyway, lastly, thruput is roughly the same with your patch and when
using the udelay.

Jacques



Confirmed here too - it works without debugging using that patch, but the kernel CPU time is pegged high whenever the drive is being accessed. I'm guessing this is because yield() won't really yield unless other threads are being scheduled...?




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to