On Tue 2016-12-13 04:58:43, Nicholas Mc Guire wrote: > useleep_range() with a delta of 0 makes no sense and only prevents the > timer subsystem from optimizing interrupts. As any user of usleep_range() > is in non-atomic context the timer jitter is in the range of 10s of > microseconds anyway. > > This adds a note making it clear that a range of 0 is a bad idea. > > Signed-off-by: Nicholas Mc Guire <hof...@osadl.org> > --- > > as of 4.9.0 there are about 20 cases of usleep_ranges() that have > min==max and none of them really look like they are necessary, so > it does seem like a relatively common misunderstanding worth > noting in the documentation. > > Patch is against 4.9.0 (localversion-next is 20161212) > > Documentation/timers/timers-howto.txt | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/Documentation/timers/timers-howto.txt > b/Documentation/timers/timers-howto.txt > index 038f8c7..b5cdf82 100644 > --- a/Documentation/timers/timers-howto.txt > +++ b/Documentation/timers/timers-howto.txt > @@ -93,6 +93,13 @@ NON-ATOMIC CONTEXT: > tolerances here are very situation specific, thus it > is left to the caller to determine a reasonable range. > > + A range of 0, that is usleep_range(100,100) or the > + like, do not make sense as this code is in a > + non-atomic section and a system can not be expected > + to have jitter 0. For any non-RT code any delta
Would it be possible to fix english here?
"to have zero jitter" at least. I believe it is "does not".
I don't see how atomic vs. non-atomic context makes difference. There
are sources of jitter that affect atomic context...
> + less than 50 microseconds probably is only preventing
> + timer subsystem optimization but providing no benefit.
And I don't trust you here. _If_ it prevents timer optimalization,
_then_ it provides benefit, at least in the average case.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
