Re: [PATCH] sched: remove sched_find_first_bit()

[Yury Norov]

On Tue, May 16, 2017 at 10:30:42AM +0200, Ingo Molnar wrote:
> 
> * Yury Norov <ynorov@xxxxxxxxxxxxxxxxxx> 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