Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755026AbZCEOh1 (ORCPT ); Thu, 5 Mar 2009 09:37:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753928AbZCEOhL (ORCPT ); Thu, 5 Mar 2009 09:37:11 -0500 Received: from qw-out-2122.google.com ([74.125.92.24]:26600 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753534AbZCEOhK (ORCPT ); Thu, 5 Mar 2009 09:37:10 -0500 Message-ID: <49AFE390.5070001@codemonkey.ws> Date: Thu, 05 Mar 2009 08:37:04 -0600 From: Anthony Liguori User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: George Dunlap CC: Jeremy Fitzhardinge , Nick Piggin , Xen-devel , the arch/x86 maintainers , Linux Kernel Mailing List , "H. Peter Anvin" , Andrew Morton Subject: Re: [Xen-devel] Re: [PATCH] xen: core dom0 support References: <1235786365-17744-1-git-send-email-jeremy@goop.org> <200902282309.07576.nickpiggin@yahoo.com.au> <49AB19E1.4050604@goop.org> <200903021737.24903.nickpiggin@yahoo.com.au> <49AB9336.7010103@goop.org> <49AEBB8C.2000405@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2696 Lines: 65 George Dunlap wrote: > On Wed, Mar 4, 2009 at 5:34 PM, Anthony Liguori 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/