WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] xen: core dom0 support

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] xen: core dom0 support
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Thu, 05 Mar 2009 08:37:04 -0600
Cc: Nick Piggin <nickpiggin@xxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 05 Mar 2009 06:37:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0903050259j5a0f9649v28e8f8fd29003d5f@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1235786365-17744-1-git-send-email-jeremy@xxxxxxxx> <200902282309.07576.nickpiggin@xxxxxxxxxxxx> <49AB19E1.4050604@xxxxxxxx> <200903021737.24903.nickpiggin@xxxxxxxxxxxx> <49AB9336.7010103@xxxxxxxx> <49AEBB8C.2000405@xxxxxxxxxxxxx> <de76405a0903050259j5a0f9649v28e8f8fd29003d5f@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
George Dunlap wrote:
On Wed, Mar 4, 2009 at 5:34 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
Can you point to benchmarks?  I have a hard time believing this.

How can shadow paging beat nested paging assuming the presence of large
pages?

If these benchmarks would help this discussion, we can certainly run
some.  As of last Fall, even with superpage support, certain workloads
perform significantly less well with HAP (hardware-assisted paging)
than with shadow pagetables.  Examples are specjbb, which does almost
no pagetable updates, but totally thrashes the TLB.

I suspected specjbb was the benchmark. specjbb is really an anomaly as it's really the only benchmark where even a naive shadow paging implementation performs very close to native.

specjbb also turns into a pathological case with HAP. In my measurements, HAP with 4k pages was close to 70% of native for specjbb. Once you enable large pages though, you get pretty close to native. IIRC, around 95%. I suspect that over time as the caching algorithms improve, this will approach 100% of native.

Then again, there are workloads like kernbench that are pathological for shadow paging in a much more dramatic way. At least on shadow2, I was seeing around 60% of native with kernbench. With direct paging, it goes to about 85% of native. With NPT and large pages, it's almost 100% of native.

  SysMark also
performed much better with shadow pagetables than HAP.  And of course,
64-bit is worse than 32-bit.  (It's actually a bit annoying from a
default-policy perspective, since about half of our workloads perform
better with HAP (up to 30% better) and half of them perform worse (up
to 30% worse)).

Our comparison would, of course, be comparing Xen+HAP to Xen+Shadow,
which isn't necessarily comparable to KVM+HAP.

Having HAP work well would be great for us as well as KVM.  But
there's still the argument about hardware support: Xen can run
paravirtualized VMs on hardware with no HVM support, and can run fully
virtualized domains very well on hardware that has HVM support but not
HAP support.

Xen is definitely not going away and as such, supporting it in Linux seems like a good idea to me. I'm just refuting claims that the Xen architecture has intrinsic advantages wrt MMU virtualization. It's simply not the case :-)

Regards,

Anthony Liguori

 -George Dunlap


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel