Hi,
This is an update to the paravirt_ops KVM backend series. I've made a
number of changes and attempted to incorporate all the feedback from the
last review. Some highlights:
1) Clean up the paravirt time source patch to use a more Xen-like model
2) Change the hypercall queueing to pass a PA on the flush hypercall
3) Add MMU support for release_{pt,pd} and TLB flush
4) Use KVM specific errno values
5) Switch from per_cpu to more appropriate functions
As for performance, I've got a few interesting results. kbuild with a
guest using 2G of memory goes from 19 minutes to 12 minutes with the
full series applied. Using 512mb, the build time goes from 10.75
minutes to 9 minutes. For 512mb, native is around 7 minutes so that's
pretty close to what Avi had seen. The more dramatic improvement with
large memory guests is probably because of the increased shadow page
table activity due to high mem.
virtbench shows major improvements but I'm not 100% confident yet in the
results as they are not very stable. I don't yet have a benchmark that
shows the benefit of the CR caching so if I don't find one, I'll drop
that from the queue.
As usual, the latest bits are available at
http://hg.codemonkey.ws/kvm-paravirt
Regards,
Anthony Liguori
Regards, Anthony Liguori -------------- next part -------------- A non-text attachment was scrubbed... Name: kvm-paravirt-core.diff Type: text/x-patch Size: 14302 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/virtualization/attachments/20070620/b1544fa5/kvm-paravirt-core.bin
This helps a lot on modern kernels where Linux is much more finicky about using the TSC as a time source. Regards, Anthony Liguori -------------- next part -------------- A non-text attachment was scrubbed... Name: kvm-paravirt-time.diff Type: text/x-patch Size: 4377 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/virtualization/attachments/20070620/44dcbd18/kvm-paravirt-time-0001.bin
Anthony Liguori
2007-Jun-20 20:07 UTC
[PATCH 3/5] KVM: Implement CR read caching for KVM paravirt_ops
Regards, Anthony Liguori -------------- next part -------------- A non-text attachment was scrubbed... Name: kvm-cr-caching.diff Type: text/x-patch Size: 4474 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/virtualization/attachments/20070620/2feb913c/kvm-cr-caching.bin
Regards, Anthony Liguori -------------- next part -------------- A non-text attachment was scrubbed... Name: kvm-mmu-write.diff Type: text/x-patch Size: 7932 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/virtualization/attachments/20070620/bc103346/kvm-mmu-write.bin
Anthony Liguori
2007-Jun-20 20:10 UTC
[PATCH 5/5] KVM: Add hypercall queue for paravirt_ops implementation
Regards, Anthony Liguori -------------- next part -------------- A non-text attachment was scrubbed... Name: kvm-hypercall-queue.diff Type: text/x-patch Size: 10102 bytes Desc: not available Url : http://lists.linux-foundation.org/pipermail/virtualization/attachments/20070620/4a72b224/kvm-hypercall-queue-0001.bin
Anthony Liguori wrote:> As usual, the latest bits are available at > http://hg.codemonkey.ws/kvm-paravirtI neglected to mention that the major missing piece right now is save/restore support. Since the VMCA is set with an MSR, I think I can just expose this MSR to userspace and add another save/restore device in QEMU. I'll need to get the real_time too to ensure that the paravirt clock remains monotonic. I figure I could make this an MSR too although that's a bit ugly. Regards, Anthony Liguori> Regards, > > Anthony Liguori >
Anthony Liguori wrote:> Hi, > > This is an update to the paravirt_ops KVM backend series. I've made a > number of changes and attempted to incorporate all the feedback from > the last review. Some highlights: > > 1) Clean up the paravirt time source patch to use a more Xen-like model > 2) Change the hypercall queueing to pass a PA on the flush hypercall > 3) Add MMU support for release_{pt,pd} and TLB flush > 4) Use KVM specific errno values > 5) Switch from per_cpu to more appropriate functions > > As for performance, I've got a few interesting results. kbuild with a > guest using 2G of memory goes from 19 minutes to 12 minutes with the > full series applied. Using 512mb, the build time goes from 10.75 > minutes to 9 minutes. For 512mb, native is around 7 minutes so that's > pretty close to what Avi had seen. The more dramatic improvement with > large memory guests is probably because of the increased shadow page > table activity due to high mem.Ah, that explains why we were getting such different results. My tests were on x86-64.> > virtbench shows major improvements but I'm not 100% confident yet in > the results as they are not very stable. I don't yet have a benchmark > that shows the benefit of the CR caching so if I don't find one, I'll > drop that from the queue. >The only barrier to merging is that we're introducing yet another stable ABI. Since we can turn off things that turn out not so good later, and expect the guest to survive, I'm not to worried, so I'm inclined to merge this. -- error compiling committee.c: too many arguments to function
>As for performance, I've got a few interesting results. kbuild with a >guest using 2G of memory goes from 19 minutes to 12 minutes with the >full series applied. Using 512mb, the build time goes from 10.75 >minutes to 9 minutes. For 512mb, native is around 7 minutes so that's >pretty close to what Avi had seen. The more dramatic improvement with >large memory guests is probably because of the increased shadow page >table activity due to high mem.Exactly, physical memory above 896M on x86_32 are mapped using temp mapping, which needs lots of invlpg instructions. On xen, it needs to wake all the shadows to find the shadow of high mem, since Xen doesn't use reverse map. On KVM, should be much better. -Xin