So the /Documentation/timers/timers-howto.txt stats: SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms): * Use usleep_range
- Why not msleep for (1ms - 20ms)? Explained originally here: http://lkml.org/lkml/2007/8/3/250 msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range). In many cases this is not the desired behavior. - Why is there no "usleep" / What is a good range? Since usleep_range is built on top of hrtimers, the wakeup will be very precise (ish), thus a simple usleep function would likely introduce a large number of undesired interrupts. With the introduction of a range, the scheduler is free to coalesce your wakeup with any other wakeup that may have happened for other reasons, or at the worst case, fire an interrupt for your upper bound. The larger a range you supply, the greater a chance that you will not trigger an interrupt; this should be balanced with what is an acceptable upper bound on delay / performance for your specific code path. Exact tolerances here are very situation specific, thus it is left to the caller to determine a reasonable range. Should the documentation should be ignored? Regards 2014-05-30 12:34 GMT+01:00 Pavel Machek <pa...@ucw.cz>: > On Fri 2014-05-30 11:27:13, Miguel Oliveira wrote: >> Creating this patch for the Eudyptula Challenge. >> Replaced msleep() for a delay < 20ms with a usleep_range() between 10000us >> and 15000us. >> Also inserted a blank line after adeclaration. > > So you are changing timings without testing. Plus, burning CPU power > instead of sleeping. > > Seems you'll need another patch for the challenge :-). > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
