From: Pavel Machek <pavel@ucw.cz>
To: Nicholas Mc Guire <hofrat@osadl.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] doc: add note on usleep_range range
Date: Tue, 27 Dec 2016 22:56:26 +0100 [thread overview]
Message-ID: <20161227215626.GA5336@amd> (raw)
In-Reply-To: <1481601523-14004-1-git-send-email-hofrat@osadl.org>
[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]
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 <hofrat@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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2016-12-27 21:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-13 3:58 [PATCH] doc: add note on usleep_range range Nicholas Mc Guire
2016-12-13 9:10 ` Jani Nikula
2016-12-13 9:19 ` Nicholas Mc Guire
2016-12-13 10:18 ` Jani Nikula
2016-12-13 12:05 ` Julia Lawall
2016-12-13 12:24 ` Nicholas Mc Guire
2016-12-14 0:27 ` Joe Perches
2016-12-14 0:37 ` Nicholas Mc Guire
2016-12-14 6:10 ` Joe Perches
2016-12-27 21:56 ` Pavel Machek [this message]
2017-01-07 19:41 ` Nicholas Mc Guire
2017-01-10 21:25 ` Pavel Machek
2017-01-11 8:50 ` Nicholas Mc Guire
2017-01-12 10:32 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161227215626.GA5336@amd \
--to=pavel@ucw.cz \
--cc=corbet@lwn.net \
--cc=hofrat@osadl.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.