* Borislav Petkov <b...@alien8.de> wrote:
> which spit this:
>
> Lazy FPU:
> 219.127929718 seconds time elapsed
> Eager FPU:
> 220.148034331 seconds time elapsed
> so we have a second slowdown and 200K FPU saves more in eager mode.
So am I interpreting the older and your latest numbers
correctly in stating that the cost observation has flipped
around 180 degrees: the first measurement showed eager FPU
to be a win, but now that we can do more precise
measurements, eager FPU has actually slowed down the kernel
build by ~0.5%?
That's not good, and kernel builds are just a random load
that isn't even that FPU or context switch heavy - there
will certainly be other loads that would be hurt even more.
So just before we base wide reaching decisions based on any
of these measurements, would you mind help us increase our
confidence in the numbers some more:
- It might make sense to do a 'perf stat --null --repeat'
measurement as well [without any -e arguments], to make
sure the rich PMU stats you are gathering are not
interfering?
With 'perf stat --null --repeat' perf acts essenially
as a /usr/bin/time replacement, but can measure down to
microseconds and will calculate noise/sttdev properly.
- Perhaps also double check the debug switch: is it
really properly switching FPU handling mode?
- Do you have enough RAM that there's essentially no IO
in the system worth speaking of? Do you have enough RAM
to copy a whole kernel tree to /tmp/linux/ and do the
measurement there, on ramfs?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
