All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Nicholas Mc Guire <hofrat@osadl.org>,
	Thomas Gleixner <tglx@linutronix.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	Nicholas Mc Guire <hofrat@osadl.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: [PATCH] doc: add note on usleep_range range
Date: Tue, 13 Dec 2016 11:10:50 +0200	[thread overview]
Message-ID: <87r35ctcrp.fsf@intel.com> (raw)
In-Reply-To: <1481601523-14004-1-git-send-email-hofrat@osadl.org>

On Tue, 13 Dec 2016, Nicholas Mc Guire <hofrat@osadl.org> 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.

So I don't really have anything to do with the timer subsystem, I'm just
their "consumer", so take this with a grain of salt.

Documentation is good, but I don't think this will be enough.

I think the only thing that will work is to detect and complain about
things like this automatically. Some ideas:

* WARN_ON(min == max) or WARN_ON_ONCE(min == max) in usleep_range()
  might be drastic, but it would get the job done eventually.

* If you want to avoid the runtime overhead (and complaints about the
  backtraces), you could wrap usleep_range() in a macro that does
  BUILD_BUG_ON(min == max) if the parameters are build time constants
  (they usually are). But you'd have to fix all the problem cases first.

* You could try (to persuade Julia or Dan) to come up with a
  cocci/smatch check for usleep_range() calls where min == max, so we
  could get bug reports for this. This probably works on expressions, so
  this would catch also cases where the parameters aren't built time
  constants.

BR,
Jani.


>
> 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
> +			less than 50 microseconds probably is only preventing
> +			timer subsystem optimization but providing no benefit.
> +
>  	SLEEPING FOR LARGER MSECS ( 10ms+ )
>  		* Use msleep or possibly msleep_interruptible

-- 
Jani Nikula, Intel Open Source Technology Center

  reply	other threads:[~2016-12-13  9:11 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 [this message]
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
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=87r35ctcrp.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@oracle.com \
    --cc=hofrat@osadl.org \
    --cc=julia.lawall@lip6.fr \
    --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.