Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: > Dependent on the already existing CONFIG_KVM_GUEST config option this patch > changes wrteei to wrtee allowing the hypervisor to rewrite those to > nontrapping > instructions. Maybe we should split the kvm guest otpimizations in two parts > one for the overhead free optimizations and on for the rest that might add > some complexity for non virtualized execution (like this one). > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> How significant is the performance impact of this change for non-virtualized systems? If it's very low, maybe you should not bother with the #ifdef, and if it's noticable, you might be better off using dynamic patching for this. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Arnd Bergmann wrote: On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> How significant is the performance impact of this change for non-virtualized systems? If it's very low, maybe you should not bother with the #ifdef, and if it's noticable, you might be better off using dynamic patching for this. Arnd <>< To be honest I unfortunately don't know how big the impact for non-virtualized systems is. I would like to test it, but without hardware performance counters on the core I have I'm not sure (yet) how to measure that in a good way - any suggestion welcome. I'm really sure that any jumping around style dynamic patching in the guest like function pointers etc will be slower than just let the load be there. Unfortunately I can not rewrite it from the hypervisor because for "wrteei" I would need a "stwi" to rewrite it in one instruction. The patch as it is today let you choose between 10% benefit for virtualized guest and an unkown but surely very small overhead on native hardware. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote: > > Arnd Bergmann wrote: > > On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: > > > >> Dependent on the already existing CONFIG_KVM_GUEST config option > this patch > >> changes wrteei to wrtee allowing the hypervisor to rewrite those to > nontrapping > >> instructions. Maybe we should split the kvm guest otpimizations in > two parts > >> one for the overhead free optimizations and on for the rest that > might add > >> some complexity for non virtualized execution (like this one). > >> > >> Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> > >> > > > > How significant is the performance impact of this change for > non-virtualized > > systems? If it's very low, maybe you should not bother with the > #ifdef, and > > if it's noticable, you might be better off using dynamic patching > for this. > > > > Arnd <>< > > > To be honest I unfortunately don't know how big the impact for > non-virtualized systems is. I would like to test it, but without > hardware performance counters on the core I have I'm not sure (yet) > how > to measure that in a good way - any suggestion welcome. I don't see why we need performance counters. Can't we just compare any bare metal benchmark results with the patch both applied and not? -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 2008-08-20 at 13:30 -0500, Hollis Blanchard wrote:
> On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
> >
> > Arnd Bergmann wrote:
> > > On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
> > >
> > >> Dependent on the already existing CONFIG_KVM_GUEST config option
> > this patch
> > >> changes wrteei to wrtee allowing the hypervisor to rewrite those to
> > nontrapping
> > >> instructions. Maybe we should split the kvm guest otpimizations in
> > two parts
> > >> one for the overhead free optimizations and on for the rest that
> > might add
> > >> some complexity for non virtualized execution (like this one).
> > >>
> > >> Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
> > >>
> > >
> > > How significant is the performance impact of this change for
> > non-virtualized
> > > systems? If it's very low, maybe you should not bother with the
> > #ifdef, and
> > > if it's noticable, you might be better off using dynamic patching
> > for this.
> > >
> > > Arnd <><
> > >
> > To be honest I unfortunately don't know how big the impact for
> > non-virtualized systems is. I would like to test it, but without
> > hardware performance counters on the core I have I'm not sure (yet)
> > how
> > to measure that in a good way - any suggestion welcome.
>
> I don't see why we need performance counters. Can't we just compare any
> bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 2008-08-20 at 14:52 -0400, Josh Boyer wrote:
> On Wed, 2008-08-20 at 13:30 -0500, Hollis Blanchard wrote:
> > On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
> > >
> > > Arnd Bergmann wrote:
> > > > On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
> > > >
> > > >> Dependent on the already existing CONFIG_KVM_GUEST config option
> > > this patch
> > > >> changes wrteei to wrtee allowing the hypervisor to rewrite those to
> > > nontrapping
> > > >> instructions. Maybe we should split the kvm guest otpimizations in
> > > two parts
> > > >> one for the overhead free optimizations and on for the rest that
> > > might add
> > > >> some complexity for non virtualized execution (like this one).
> > > >>
> > > >> Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]>
> > > >>
> > > >
> > > > How significant is the performance impact of this change for
> > > non-virtualized
> > > > systems? If it's very low, maybe you should not bother with the
> > > #ifdef, and
> > > > if it's noticable, you might be better off using dynamic patching
> > > for this.
> > > >
> > > > Arnd <><
> > > >
> > > To be honest I unfortunately don't know how big the impact for
> > > non-virtualized systems is. I would like to test it, but without
> > > hardware performance counters on the core I have I'm not sure (yet)
> > > how
> > > to measure that in a good way - any suggestion welcome.
> >
> > I don't see why we need performance counters. Can't we just compare any
> > bare metal benchmark results with the patch both applied and not?
>
> Do you know of one that causes a large amount of
> local_irq_{disable,enable}s to be called?
I think *every* workload causes a large number of
local_irq_{disable,enable} calls... :)
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 20 Aug 2008 14:06:51 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> > > > To be honest I unfortunately don't know how big the impact for
> > > > non-virtualized systems is. I would like to test it, but without
> > > > hardware performance counters on the core I have I'm not sure (yet)
> > > > how
> > > > to measure that in a good way - any suggestion welcome.
> > >
> > > I don't see why we need performance counters. Can't we just compare any
> > > bare metal benchmark results with the patch both applied and not?
> >
> > Do you know of one that causes a large amount of
> > local_irq_{disable,enable}s to be called?
>
> I think *every* workload causes a large number of
> local_irq_{disable,enable} calls... :)
Well, sure. I was just going for "test the change as specifically as
possible." One could write a module that did X number of
disable/enable pairs and reported the timebase at start and end to
compare. X could even be a module parameter. Just to try and
eliminate noise or whatever from the testing.
/me shrugs.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Josh Boyer wrote:
On Wed, 20 Aug 2008 14:06:51 -0500
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
To be honest I unfortunately don't know how big the impact for
non-virtualized systems is. I would like to test it, but without
hardware performance counters on the core I have I'm not sure (yet)
how
to measure that in a good way - any suggestion welcome.
I don't see why we need performance counters. Can't we just compare any
bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
I think *every* workload causes a large number of
local_irq_{disable,enable} calls... :)
Well, sure. I was just going for "test the change as specifically as
possible." One could write a module that did X number of
disable/enable pairs and reported the timebase at start and end to
compare. X could even be a module parameter. Just to try and
eliminate noise or whatever from the testing.
/me shrugs.
josh
yeah I thought of something like that too, because I expect the
difference to be very small.
Instead of a module I wanted to put this somewhere prior to the kernel
mounting root-fs to avoid interferences from whatever userspace is doing
(e.g. causing thousands of interrupts come back while the module
perform that test.).
Eventually we need a synthetic benchmark like that AND a check how it
affects a common system to be sure.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- So this commit message doesnt explain why 'wrtee' facilities doing whatever optimization and 'wrteei' doesnt. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Kumar Gala wrote: On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- So this commit message doesnt explain why 'wrtee' facilities doing whatever optimization and 'wrteei' doesnt. yep I only explained it elsewhere. I'll add it here too in the next version - thanks Kumar (and fix the word otpimizations) -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 21, 2008, at 9:13 AM, Christian Ehrhardt wrote: Kumar Gala wrote: On Aug 19, 2008, at 5:36 AM, [EMAIL PROTECTED] wrote: From: Christian Ehrhardt <[EMAIL PROTECTED]> Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> --- So this commit message doesnt explain why 'wrtee' facilities doing whatever optimization and 'wrteei' doesnt. yep I only explained it elsewhere. I'll add it here too in the next version - thanks Kumar (and fix the word otpimizations) Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: > Where is the other discussion? I'd like to understand what's going on > here.. (especially since I added the wrtee[i] changes to kernel way > back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Scott Wood wrote: On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott Exactly Scott And for your question Kumar, in the last submission I was asked to split host and guest patches. So the host discussion lives on [EMAIL PROTECTED] as I mentioned (maybe a bit too hidden) in the [0/4] mail of this series. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 22, 2008, at 3:08 AM, Christian Ehrhardt wrote: Scott Wood wrote: On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott Exactly Scott And for your question Kumar, in the last submission I was asked to split host and guest patches. So the host discussion lives on [EMAIL PROTECTED] as I mentioned (maybe a bit too hidden) in the [0/4] mail of this series. Maybe I'm missing something but it seems like just changing the code to wrtee isn't the best way to ensure you have enough space to put the set of instructions you guys want. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Aug 22, 2008, at 4:17 AM, Kumar Gala wrote: On Aug 22, 2008, at 3:08 AM, Christian Ehrhardt wrote: Scott Wood wrote: On Thu, Aug 21, 2008 at 09:21:39AM -0500, Kumar Gala wrote: Where is the other discussion? I'd like to understand what's going on here.. (especially since I added the wrtee[i] changes to kernel way back when). Presumably, they want to be able to replace wrtee with a store to a hypervisor/guest shared memory area, and there's no store-immediate instruction. -Scott Exactly Scott And for your question Kumar, in the last submission I was asked to split host and guest patches. So the host discussion lives on [EMAIL PROTECTED] as I mentioned (maybe a bit too hidden) in the [0/4] mail of this series. Maybe I'm missing something but it seems like just changing the code to wrtee isn't the best way to ensure you have enough space to put the set of instructions you guys want. Sorry, I have not really been following this, I assume you are replacing SPR accesses with load/stores that do not trap. I believe thats fine for reading any SPR, but not true for modifying some SPRs, particularly MSR. IMHO you must trap on any instruction that modifies the MSR. So you should prolly not rewrite mtmsr or wrtee* but let them trap. BTW: actually moving problem SPRs (like MSRs) to a read only page makes decoding far more efficient, but it does burn another TLB entry. -JX - k -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Fri, Aug 22, 2008 at 09:56:16AM -0400, Jimi Xenidis wrote: > Sorry, I have not really been following this, I assume you are > replacing SPR accesses with load/stores that do not trap. > I believe thats fine for reading any SPR, but not true for modifying > some SPRs, particularly MSR. > IMHO you must trap on any instruction that modifies the MSR. > So you should prolly not rewrite mtmsr or wrtee* but let them trap. You only need to trap when changing MSR[EE] if there's a pending interrupt. The hypervisor can change the mapping of the shared page when it is unable to deliver an interrupt due to the virtual EE value being zero. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
