[RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness

[Caraman Mihai Claudiu-B02008]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, June 05, 2013 1:54 AM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc at vger.kernel.org; kvm at vger.kernel.org; linuxppc-
> dev at lists.ozlabs.org; Caraman Mihai Claudiu-B02008
> Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
> 
> On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> > Adopt AltiVec approach to increase laziness by calling
> > kvmppc_load_guest_fp()
> > just before returning to guest instaed of each sched in.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman at freescale.com>
> 
> If you did this *before* adding Altivec it would have saved a question
> in an earlier patch. :-)

I kept asking myself about the order and in the end I decided that this is
an improvement originated from AltiVec work. FPU may be further cleaned up
(get rid of active state, etc). 

> 
> > ---
> >  arch/powerpc/kvm/booke.c  |    1 +
> >  arch/powerpc/kvm/e500mc.c |    2 --
> >  2 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index 019496d..5382238 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -1258,6 +1258,7 @@ int kvmppc_handle_exit(struct kvm_run *run,
> > struct kvm_vcpu *vcpu,
> >  		} else {
> >  			kvmppc_lazy_ee_enable();
> >  			kvmppc_load_guest_altivec(vcpu);
> > +			kvmppc_load_guest_fp(vcpu);
> >  		}
> >  	}
> >
> 
> You should probably do these before kvmppc_lazy_ee_enable().

Why? I wanted to look like part of lightweight_exit.

> 
> Actually, I don't think this is a good idea at all.  As I understand
> it, you're not supposed to take kernel ownersship of floating point in
> non-atomic context, because an interrupt could itself call
> enable_kernel_fp().

So lightweight_exit isn't executed in atomic context?

Will be lazyee fixes including  kvmppc_fix_ee_before_entry() in 3.10?
64-bit Book3E KVM is unreliable without them. Should we disable e5500 too
for 3.10?
 
> Do you have benchmarks showing it's even worthwhile?

No yet but isn't this the whole idea of FPU/AltiVec laziness that the kernel
is struggling to achieve? Without it when returning to host (if another process
got unit ownership in handle_exit) we restore and save the unit state for nothing.
This multiplies when the ownership goes back and forth between handle_exit and other
processes.

Do you have in mid a specific AltiVec benchmark? I have a stress application that do
consecutive vector assignments which proved to be very good at finding state
corruptions. If I combine this application on the host with a guest that stays longer
on handle_exit (running a tlb or emulation intensive application) I might have good
data to support my case.

-Mike



> 
> -Scott