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 --]
prev parent 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.