| Message ID | 1370292868-2697-7-git-send-email-mihai.caraman@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> -----Original Message----- > From: Wood Scott-B07421 > Sent: Wednesday, June 05, 2013 1:54 AM > To: Caraman Mihai Claudiu-B02008 > Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc- > dev@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@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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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); } } diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c index 9d7f38e..29cf97a 100644 --- a/arch/powerpc/kvm/e500mc.c +++ b/arch/powerpc/kvm/e500mc.c @@ -138,8 +138,6 @@ void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu) if (vcpu->arch.oldpir != mfspr(SPRN_PIR)) kvmppc_e500_tlbil_all(vcpu_e500); - - kvmppc_load_guest_fp(vcpu); } void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
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@freescale.com> --- arch/powerpc/kvm/booke.c | 1 + arch/powerpc/kvm/e500mc.c | 2 -- 2 files changed, 1 insertions(+), 2 deletions(-)