On Tue, 24 Jan 2012 15:07:50 +0100, Olivier Sobrie wrote: > I performed the same test you did on my system and I observed this: > > * msleep(1) > real 0m 51.20s > user 0m 0.29s > sys 0m 0.00s I assume your kernel has HZ=100, that means 20 ms per transaction i.e. 2 jiffies, as expected from the msleep() implementation. > > * usleep_range(100, 200) > real 0m 1.46s > user 0m 0.10s > sys 0m 0.10s > > * usleep_range(250, 500) > real 0m 2.01s > user 0m 0.05s > sys 0m 0.25s It's really curious that this can take more CPU time than usleep_range(100, 200). I can't explain it. > > * usleep_range(50, 150) > real 0m 1.43s > user 0m 0.07s > sys 0m 0.23s > > I think usleep_range(100, 200) is the best compromise. I agree. > (...) > I agree udelay() is not a good solution! > I did the test without hrtimers using usleep_range(100, 200) and got: > real 0m 25.60s > user 0m 0.30s > sys 0m 0.00s > So that's not slower than msleep(1) in the case of no hrtimers. In fact that's exactly twice as fast as msleep(2), i.e. 1 jiffy per transaction instead of 2. That's pretty good that there is a benefit even without hrtimers support. Thanks for testing and reporting, that's one less thing on my to-do list :) I'll send a patch similar to yours for the i2c-i801 driver in a minute. Thanks for showing us the way! -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
