On Sun, Feb 22, 2015 at 09:18:40AM +0100, Ingo Molnar wrote:
> 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%?

Well, I wouldn't take the latest numbers too seriously - that was a
single run without --repeat.

> 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.

That is my fear.

> 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.

and I'm clearing/setting eager FPU with
setup_force_cpu_cap/setup_clear_cpu_cap, see full diff below.

> - 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?

/proc/meminfo says "MemTotal: 4011860 kB" which is probably not enough.
But I could find one somewhere :-)