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