* Andy Lutomirski <l...@amacapital.net> wrote:
> We have eager and lazy fpu modes, introduced in:
>
> 304bceda6a18 x86, fpu: use non-lazy fpu restore for processors supporting
> xsave
>
> The result is rather messy. There are two code paths in
> almost all of the FPU code, and only one of them (the
> eager case) is tested frequently, since most kernel
> developers have new enough hardware that we use eagerfpu.
>
> It seems that, on any remotely recent hardware, eagerfpu
> is a win: glibc uses SSE2, so laziness is probably
> overoptimistic, and, in any case, manipulating TS is far
> slower that saving and restoring the full state.
>
> To try to shake out any latent issues on old hardware,
> this changes the default to eager on all CPUs. If no
> performance or functionality problems show up, a
> subsequent patch could remove lazy mode entirely.
So it would be nice to test this on at least one reasonably
old (but not uncomfortably old - say 5 years old) system,
to get a feel for what kind of performance impact it has
there.
But yes, this would enable a nice simplification in the end
so I'm all for it as long as it doesn't cause unacceptable
problems - and the FPU code needs simplification badly,
because the current latency of bug discovery is too high
IMO.
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/
