[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMGgR5swX-cp4navRBu8CxYnL5fRSxkBVRcu-xKXkr0oyBXP+A@mail.gmail.com>
Date: Fri, 30 May 2014 13:15:12 +0100
From: Miguel Oliveira <cmroliv@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: gregkh@...uxfoundation.org, gulsah.1004@...il.com,
pali.rohar@...il.com, peter.p.waskiewicz.jr@...el.com,
kristina.martsenko@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: nokia_h4: nokia_core.c: use usleep_range()
instead of msleep()
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 <pavel@....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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists