Re: [PATCH 00/27] KVM PPC PV framework v3
On 06.08.2010, at 18:28, Kumar Gala wrote:
>
> On Jul 29, 2010, at 7:47 AM, Alexander Graf wrote:
>
>> [without]
>>
>> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null;
>> done
>>
>> real0m14.659s
>> user0m8.967s
>> sys 0m5.688s
>>
>> [with]
>>
>> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null;
>> done
>>
>> real0m7.557s
>> user0m4.121s
>> sys 0m3.426s
>
> Do you have #'s for w/o HV to compare to.
Native was around 2-3 seconds overall. So we still have quite a big impact on
performance, but things are improving :).
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On Jul 29, 2010, at 7:47 AM, Alexander Graf wrote:
> [without]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null;
> done
>
> real0m14.659s
> user0m8.967s
> sys 0m5.688s
>
> [with]
>
> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null;
> done
>
> real0m7.557s
> user0m4.121s
> sys 0m3.426s
Do you have #'s for w/o HV to compare to.
- k--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On 07/29/2010 03:47 PM, Alexander Graf wrote:
On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
hypervisor extensions.
While that is all great to show that virtualization is possible, there are
quite some cases where the emulation overhead of privileged instructions is
killing performance.
This patchset tackles exactly that issue. It introduces a paravirtual framework
using which KVM and Linux share a page to exchange register state with. That
way we don't have to switch to the hypervisor just to change a value of a
privileged register.
To prove my point, I ran the same test I did for the MMU optimizations against
the PV framework. Here are the results:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
real0m7.557s
user0m4.121s
sys 0m3.426s
So this is a significant performance improvement! I'm quite happy how fast this
whole thing becomes :)
I tried to take all comments I've heard from people so far about such a PV
framework into account. In case you told me something before that is a no-go
and I still did it, please just tell me again.
To make use of this whole thing you also need patches to qemu and openbios. I
have them in my queue, but want to see this set upstream first before I start
sending patches to the other projects.
Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
experiencing the power yourself. - heh
Applied this and your follow on 7-part series, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On 08/05/2010 11:01 AM, Alexander Graf wrote: Shall I take this as an ACK? Hollis wanted to take a look at it too. But given the fact that I have another ~10 patches lying here I'd appreciate if things could get committed. If changes are so dramatic that they'd render things incompatible, we can always just release both patches for an actual kernel release, right? That's true, we have some time to get it right. Hollis, please let us know either way once you've reviewed things. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On 05.08.2010, at 09:57, Avi Kivity wrote: > On 08/03/2010 07:16 PM, Scott Wood wrote: >> On Sun, 1 Aug 2010 22:21:37 +0200 >> Alexander Graf wrote: >> >>> On 01.08.2010, at 16:02, Avi Kivity wrote: >>> Looks reasonable. Since it's fair to say I understand nothing about powerpc, I'd like someone who does to review it and ack, please, with an emphasis on the interfaces. >>> Sounds good. Preferably someone with access to the ePAPR spec :). >> The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable. >> Did I miss any ePAPR-relevant stuff in the other patches? > > Shall I take this as an ACK? Hollis wanted to take a look at it too. But given the fact that I have another ~10 patches lying here I'd appreciate if things could get committed. If changes are so dramatic that they'd render things incompatible, we can always just release both patches for an actual kernel release, right? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On 08/03/2010 07:16 PM, Scott Wood wrote: On Sun, 1 Aug 2010 22:21:37 +0200 Alexander Graf wrote: On 01.08.2010, at 16:02, Avi Kivity wrote: Looks reasonable. Since it's fair to say I understand nothing about powerpc, I'd like someone who does to review it and ack, please, with an emphasis on the interfaces. Sounds good. Preferably someone with access to the ePAPR spec :). The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable. Did I miss any ePAPR-relevant stuff in the other patches? Shall I take this as an ACK? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On Sun, 1 Aug 2010 22:21:37 +0200 Alexander Graf wrote: > > On 01.08.2010, at 16:02, Avi Kivity wrote: > > > Looks reasonable. Since it's fair to say I understand nothing about > > powerpc, I'd like someone who does to review it and ack, please, with an > > emphasis on the interfaces. > > Sounds good. Preferably someone with access to the ePAPR spec :). The ePAPR-relevant stuff in patches 7, 16, and 17 looks reasonable. Did I miss any ePAPR-relevant stuff in the other patches? -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On 01.08.2010, at 16:02, Avi Kivity wrote:
> On 07/29/2010 03:47 PM, Alexander Graf wrote:
>> On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
>> hypervisor extensions.
>>
>> While that is all great to show that virtualization is possible, there are
>> quite some cases where the emulation overhead of privileged instructions is
>> killing performance.
>>
>> This patchset tackles exactly that issue. It introduces a paravirtual
>> framework
>> using which KVM and Linux share a page to exchange register state with. That
>> way we don't have to switch to the hypervisor just to change a value of a
>> privileged register.
>>
>> To prove my point, I ran the same test I did for the MMU optimizations
>> against
>> the PV framework. Here are the results:
>>
>> [without]
>>
>> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null;
>> done
>>
>> real0m14.659s
>> user0m8.967s
>> sys 0m5.688s
>>
>> [with]
>>
>> debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null;
>> done
>>
>> real0m7.557s
>> user0m4.121s
>> sys 0m3.426s
>>
>>
>> So this is a significant performance improvement! I'm quite happy how fast
>> this
>> whole thing becomes :)
>>
>> I tried to take all comments I've heard from people so far about such a PV
>> framework into account. In case you told me something before that is a no-go
>> and I still did it, please just tell me again.
>>
>> To make use of this whole thing you also need patches to qemu and openbios. I
>> have them in my queue, but want to see this set upstream first before I start
>> sending patches to the other projects.
>>
>> Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
>> experiencing the power yourself. - heh
>>
>> v1 -> v2:
>>
>> - change hypervisor calls to use r0 and r3
>> - make crit detection only trigger in supervisor mode
>> - RMO -> PAM
>> - introduce kvm_patch_ins
>> - only flush icache when patching
>> - introduce kvm_patch_ins_b
>> - update documentation
>>
>> v2 -> v3:
>>
>> - use pPAPR conventions for hypercall interface
>> - only use r0 as magic sc number
>> - remove PVR detection
>> - remove BookE shared page mapping support
>> - combine book3s-64 and -32 magic page ra override
>> - add self-test check if the mapping works to guest code
>> - add safety check for relocatable kernels
>>
>
> Looks reasonable. Since it's fair to say I understand nothing about powerpc,
> I'd like someone who does to review it and ack, please, with an emphasis on
> the interfaces.
Sounds good. Preferably someone with access to the ePAPR spec :).
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework v3
On 07/29/2010 03:47 PM, Alexander Graf wrote:
On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
hypervisor extensions.
While that is all great to show that virtualization is possible, there are
quite some cases where the emulation overhead of privileged instructions is
killing performance.
This patchset tackles exactly that issue. It introduces a paravirtual framework
using which KVM and Linux share a page to exchange register state with. That
way we don't have to switch to the hypervisor just to change a value of a
privileged register.
To prove my point, I ran the same test I did for the MMU optimizations against
the PV framework. Here are the results:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello> /dev/null; done
real0m7.557s
user0m4.121s
sys 0m3.426s
So this is a significant performance improvement! I'm quite happy how fast this
whole thing becomes :)
I tried to take all comments I've heard from people so far about such a PV
framework into account. In case you told me something before that is a no-go
and I still did it, please just tell me again.
To make use of this whole thing you also need patches to qemu and openbios. I
have them in my queue, but want to see this set upstream first before I start
sending patches to the other projects.
Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
experiencing the power yourself. - heh
v1 -> v2:
- change hypervisor calls to use r0 and r3
- make crit detection only trigger in supervisor mode
- RMO -> PAM
- introduce kvm_patch_ins
- only flush icache when patching
- introduce kvm_patch_ins_b
- update documentation
v2 -> v3:
- use pPAPR conventions for hypercall interface
- only use r0 as magic sc number
- remove PVR detection
- remove BookE shared page mapping support
- combine book3s-64 and -32 magic page ra override
- add self-test check if the mapping works to guest code
- add safety check for relocatable kernels
Looks reasonable. Since it's fair to say I understand nothing about
powerpc, I'd like someone who does to review it and ack, please, with an
emphasis on the interfaces.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
