linux-kernel - Re: [PATCH] doc: add note on usleep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Jan 2017 22:25:29 +0100
From:   Pavel Machek <pavel@....cz>
To:     Nicholas Mc Guire <der.herr@...r.at>
Cc:     Nicholas Mc Guire <hofrat@...dl.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH] doc: add note on usleep_range range

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.

> > > +			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.
> >
> here is the data:
> 
> 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)
> 
> Test-setup - poped this into akernel module and just 
> brute force load/unload it in a loop - not very elegant
> but it does the job.
> 
> static int __init usleep_test_init(void)
> {
>         ktime_t now,last;
>         unsigned long min,max;
>         min = 200;
>         max = 250;
>         last = ktime_get();
>         usleep_range(min, max);
>         now = ktime_get();
>         printk("%llu\n", ktime_to_ns(now)-ktime_to_ns(last));
>         return 0;
> }
> 
> Results:
> 
> 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).

Thanks,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)