From: Scott Wood <scottwood@freescale.com>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
Mihai Caraman <mihai.caraman@freescale.com>
Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
Date: Tue, 04 Jun 2013 22:53:52 +0000 [thread overview]
Message-ID: <1370386432.748.22@snotra> (raw)
In-Reply-To: <1370292868-2697-7-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:28 2013)
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. :-)
> ---
> 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().
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().
Do you have benchmarks showing it's even worthwhile?
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: Mihai Caraman <mihai.caraman@freescale.com>,
linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
Date: Tue, 4 Jun 2013 17:53:52 -0500 [thread overview]
Message-ID: <1370386432.748.22@snotra> (raw)
In-Reply-To: <1370292868-2697-7-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:28 2013)
On 06/03/2013 03:54:28 PM, Mihai Caraman wrote:
> Adopt AltiVec approach to increase laziness by calling =20
> kvmppc_load_guest_fp()
> just before returning to guest instaed of each sched in.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
If you did this *before* adding Altivec it would have saved a question =20
in an earlier patch. :-)
> ---
> arch/powerpc/kvm/booke.c | 1 +
> arch/powerpc/kvm/e500mc.c | 2 --
> 2 files changed, 1 insertions(+), 2 deletions(-)
>=20
> 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, =20
> struct kvm_vcpu *vcpu,
> } else {
> kvmppc_lazy_ee_enable();
> kvmppc_load_guest_altivec(vcpu);
> + kvmppc_load_guest_fp(vcpu);
> }
> }
>=20
You should probably do these before kvmppc_lazy_ee_enable().
Actually, I don't think this is a good idea at all. As I understand =20
it, you're not supposed to take kernel ownersship of floating point in =20
non-atomic context, because an interrupt could itself call =20
enable_kernel_fp().
Do you have benchmarks showing it's even worthwhile?
-Scott=
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>,
<linuxppc-dev@lists.ozlabs.org>,
Mihai Caraman <mihai.caraman@freescale.com>
Subject: Re: [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness
Date: Tue, 4 Jun 2013 17:53:52 -0500 [thread overview]
Message-ID: <1370386432.748.22@snotra> (raw)
In-Reply-To: <1370292868-2697-7-git-send-email-mihai.caraman@freescale.com> (from mihai.caraman@freescale.com on Mon Jun 3 15:54:28 2013)
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. :-)
> ---
> 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().
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().
Do you have benchmarks showing it's even worthwhile?
-Scott
next prev parent reply other threads:[~2013-06-04 22:53 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 20:54 [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 1/6] KVM: PPC: Book3E: Fix AltiVec interrupt numbers and build breakage Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` [RFC PATCH 2/6] KVM: PPC: Book3E: Refactor SPE_FP exit handling Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:14 ` Scott Wood
2013-06-04 22:14 ` Scott Wood
2013-06-04 22:14 ` Scott Wood
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:29 ` Caraman Mihai Claudiu-B02008
2013-06-05 19:07 ` Scott Wood
2013-06-05 19:07 ` Scott Wood
2013-06-05 19:07 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 3/6] KVM: PPC: Book3E: Rename IRQPRIO names to accommodate ALTIVEC Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:28 ` Scott Wood
2013-06-04 22:28 ` Scott Wood
2013-06-04 22:28 ` Scott Wood
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:52 ` Caraman Mihai Claudiu-B02008
2013-06-03 20:54 ` [RFC PATCH 4/6] KVM: PPC: Book3E: Add AltiVec support Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:36 ` Scott Wood
2013-06-04 22:36 ` Scott Wood
2013-06-04 22:36 ` Scott Wood
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:23 ` Caraman Mihai Claudiu-B02008
2013-06-03 20:54 ` [RFC PATCH 5/6] KVM: PPC: Book3E: Add ONE_REG " Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:40 ` Scott Wood
2013-06-04 22:40 ` Scott Wood
2013-06-04 22:40 ` Scott Wood
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 12:11 ` Caraman Mihai Claudiu-B02008
2013-07-03 18:31 ` Scott Wood
2013-07-03 18:31 ` Scott Wood
2013-07-03 18:31 ` Scott Wood
2013-06-03 20:54 ` [RFC PATCH 6/6] KVM: PPC: Book3E: Enhance FPU laziness Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-03 20:54 ` Mihai Caraman
2013-06-04 22:53 ` Scott Wood [this message]
2013-06-04 22:53 ` Scott Wood
2013-06-04 22:53 ` Scott Wood
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 9:14 ` Caraman Mihai Claudiu-B02008
2013-06-05 20:59 ` Scott Wood
2013-06-05 20:59 ` Scott Wood
2013-06-05 20:59 ` Scott Wood
2013-06-04 21:39 ` [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support Scott Wood
2013-06-04 21:39 ` Scott Wood
2013-06-04 21:39 ` Scott Wood
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 7:10 ` Caraman Mihai Claudiu-B02008
2013-06-05 16:35 ` Scott Wood
2013-06-05 16:35 ` Scott Wood
2013-06-05 16:35 ` Scott Wood
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 9:42 ` Caraman Mihai Claudiu-B02008
2013-06-06 19:57 ` Scott Wood
2013-06-06 19:57 ` Scott Wood
2013-06-06 19:57 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1370386432.748.22@snotra \
--to=scottwood@freescale.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mihai.caraman@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.