Re: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU

[Avi Kivity <avi@redhat.com>]

On 09/26/2012 07:54 AM, Hao, Xudong wrote:
>> -----Original Message-----
>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
>> Behalf Of Avi Kivity
>> Sent: Tuesday, September 25, 2012 4:16 PM
>> To: Hao, Xudong
>> Cc: kvm@vger.kernel.org; Zhang, Xiantao
>> Subject: Re: [PATCH v4] kvm/fpu: Enable fully eager restore kvm FPU
>> 
>> On 09/25/2012 04:32 AM, Hao, Xudong wrote:
>> > >
>> > > btw, it is clear that long term the fpu will always be eagerly loaded,
>> > > as hosts and guests (and hardware) are updated.  At that time it will
>> > > make sense to remove the lazy fpu code entirely.  But maybe that time is
>> > > here already, since exits are rare and so the guest has a lot of chance
>> > > to use the fpu, so eager fpu saves the #NM vmexit.
>> > >
>> > > Can you check a kernel compile on a westmere system?  If eager fpu is
>> > > faster there than lazy fpu, we can just make the fpu always eager and
>> > > remove quite a bit of code.
>> > >
>> > I remember westmere does not support Xsave, do you want performance of
>> fxsave/fresotr ?
>> 
>> Yes.   If a westmere is fast enough then we can probably justify it.  If
>> you can run tests on Sandy/Ivy Bridge, even better.
>> 
> Run kernel compile on westmere, eager fpu is about 0.4% faster, seems eager does not benefit it too much, so remain lazy fpu for lazy_allowed fpu state?

Why not make it eager all the time then?  It will simplify the code
quite a bit, no?

All I was looking for was no regressions, a small speedup is just a bonus.

-- 
error compiling committee.c: too many arguments to function