All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: Nicholas Mc Guire <hofrat@osadl.org>,
	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: Thu, 12 Jan 2017 11:32:07 +0100	[thread overview]
Message-ID: <20170112103207.GG29366@amd> (raw)
In-Reply-To: <20170111085007.GA13195@osadl.at>

[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]

On Wed 2017-01-11 08:50:07, Nicholas Mc Guire wrote:
> On Tue, Jan 10, 2017 at 10:25:29PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > "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...
> > > 
> > > The relevance is that while there is jitter in atomic context it can
> > > be quite small (depending on your hardware and the specifics of system
> > > config) but in non-atomic context the jitter is so large that it
> > > makes no relevant difference if you give usleep_range slack of a few
> > > microseconds.
> > 
> > I disagree here. Even in non-atomic code, you'll get _no_ jitter most
> > of the time. If you care about average case, small slack may still
> > make sense.
> 
> yes - thats what the results say - the mean does not differe significantly
> so if you care about average case - it makes no difference.

You did not demonstrate that.

> > > usleep_range() 5000 samples - idle system 
> > >  100,100         200,200         190,200
> > >  Min.   :188481  Min.   :201917  Min.   :197793
> > >  1st Qu.:207062  1st Qu.:207057  1st Qu.:207051
> > >  Median :207139  Median :207133  Median :207133
> > >  Mean   :207254  Mean   :207233  Mean   :207244
> > >  3rd Qu.:207341  erd Qu.:207262  3rd Qu.:207610
> > >  Max.   :225340  Max.   :214222  Max.   :214885
> > > 
> > > 100,200 to 200,200 is maybe relevant impact for
> > > some systems with respect to the outliers, but
> > > mean and median are almost the same, for
> > > 190,200 to 200,200 there is statistically no
> > > significant difference with respect to performance
> > > Note that the timestamp before and after also has
> > > jitter - so only part of the jitter can be attributed
> > > to usleep_range() it self. But idle system optimization
> > > is not that interesting for most systems.
> > 
> > I disagree here. Most of systems are idle, most of the time. You say
> > that basically everyone should provide 50 usec of slack... So I guess
> > I'd like to see comparisons for 200,200 and 200,250 (and perhaps also
> > 200,500 or something).
> >
> I did not say that everyone should use 50us of slack - rather the statement 
> was "makes no relevant difference if you give usleep_range slack of a few
> microseconds." and that min==max makes *no* sense and that providing 
> even just small slack (in 10s of us range) makes a relevant difference 
> at system level.

You did not demonstrate any "relevant difference at system level".

									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 --]

      reply	other threads:[~2017-01-12 10:32 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
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 [this message]

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=20170112103207.GG29366@amd \
    --to=pavel@ucw.cz \
    --cc=corbet@lwn.net \
    --cc=der.herr@hofr.at \
    --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.