From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752802AbdAJVZf (ORCPT ); Tue, 10 Jan 2017 16:25:35 -0500 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:35051 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbdAJVZd (ORCPT ); Tue, 10 Jan 2017 16:25:33 -0500 Date: Tue, 10 Jan 2017 22:25:29 +0100 From: Pavel Machek To: Nicholas Mc Guire Cc: Nicholas Mc Guire , Thomas Gleixner , Jonathan Corbet , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH] doc: add note on usleep_range range Message-ID: <20170110212529.GC25738@amd> References: <1481601523-14004-1-git-send-email-hofrat@osadl.org> <20161227215626.GA5336@amd> <20170107194150.GA22557@osadl.at> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uh9ZiVrAOUUm9fzH" Content-Disposition: inline In-Reply-To: <20170107194150.GA22557@osadl.at> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --uh9ZiVrAOUUm9fzH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > "to have zero jitter" at least. I believe it is "does not". > >=20 > > I don't see how atomic vs. non-atomic context makes difference. There > > are sources of jitter that affect atomic context... >=20 > 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. > > > + less than 50 microseconds probably is only preventing > > > + timer subsystem optimization but providing no benefit. > >=20 > > And I don't trust you here. _If_ it prevents timer optimalization, > > _then_ it provides benefit, at least in the average case. > > > here is the data: >=20 > System: Intel Core i7 CPU 920 @ 2.67GHz Ocotocore > OS: Debian 8.1 (but thats quite irrelevant) > Kernel: 4.10-rc2 (localversion-next next-20170106) > config: x86_64_defconfig (Voluntary | Preempt) >=20 > Test-setup - poped this into akernel module and just=20 > brute force load/unload it in a loop - not very elegant > but it does the job. >=20 > static int __init usleep_test_init(void) > { > ktime_t now,last; > unsigned long min,max; > min =3D 200; > max =3D 250; > last =3D ktime_get(); > usleep_range(min, max); > now =3D ktime_get(); > printk("%llu\n", ktime_to_ns(now)-ktime_to_ns(last)); > return 0; > } >=20 > Results: >=20 > usleep_range() 5000 samples - idle system=20 > 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 >=20 > 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). Thanks, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --uh9ZiVrAOUUm9fzH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlh1UUkACgkQMOfwapXb+vJNlACfYS3nf/eOK6jkDoMvM6aa5lMP kiAAmgORCXM4OyrUdy4gk+hftJkwjDvZ =1vv7 -----END PGP SIGNATURE----- --uh9ZiVrAOUUm9fzH--