linux-kernel - Re: [PATCH] sched: remove sched_find_first

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:   Wed, 17 May 2017 15:16:36 +0300
From:   Yury Norov <ynorov@...iumnetworks.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Akinobu Mita <mita@...aclelinux.com>,
        Mike Galbraith <efault@....de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH] sched: remove sched_find_first_bit()

On Tue, May 16, 2017 at 10:30:42AM +0200, Ingo Molnar wrote:
> 
> * Yury Norov <ynorov@...iumnetworks.com> wrote:
> 
> > I collected about 700 results in dmesg, and took 600 fastest.
> > For the vanilla kernel, the average value is 368, and for patched
> > kernel it is 388. It's 5% slower. But the standard deviation is 
> > really big for both series' - 131 and 106 cycles respectively, which
> > is ~ 30%. And so, my conclusion is: there's no benefit in using
> > sched_find_first_bit() comparing to find_first_bit().
> 
> Erm, so you in essence claim:
> 
> 	"according to measurements the new code is 5% slower, with a high, 30% 
> 	 stddev, hence the new code is better!"
> 
> Basic logic fail...
> 
> Thanks,
> 
> 	Ingo

No, in essence I claim that scatter is so big (in both cases, and in
case of vanilla kernel even bigger) that 5% is not a meaningful
difference. To be specific - new measured value is inside the
confidence interval of previous one.

In fact I repeated measurements many times, and results always
different. Even 2 consequent measurements in the same configuration
may show difference ~10-15%. Arnd's unrolled version generates almost
identical assembler code, but also slower.

After all that fun, I think that measuring average value of the
function execution time is not the suitable approach. Maybe in this
case it would be better to compare fastest runs.

Anyway, are you OK if I drop alpha's implementation of sched_find_first_bit(),
move it to kernel/sched/rt.c and remove include/asm-generic/bitops/sched.h,
as Arnd suggested?

Yury