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
