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/
Home Products Support Community News


Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][Patches] Xen 1GB Page Table Support
From: Gianluca Guida <glguida@xxxxxxxxx>
Date: Fri, 20 Mar 2009 14:59:40 +0100
Cc: Gianluca.guida@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Wei Huang <wei.huang2@xxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 20 Mar 2009 07:00:13 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UPWnY25XpnaiMd6pqN5MXXpDoXB1ySKldIUe9bHg3UA=; b=LIJDPGkPOgptl4gvaP1WuqrNRtemT1OxTi8Ljysf/2NWJTnde9ENJA2wAQ3eRgJ3oC v/ShBzOVdZump3/t8FLJEax1l089332HKX33gO9XEkKPrzwVWZTg1dSiEF9/Y+xd+gyN 1bSVVEePWoral7/+SAShGNYXjYT38D6One1zM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qFOOLj2A22VPOpzhRDhbzkQ74Molvfs+jhMIizYiDBoBPnEpR6MAjC7jvPXyaB0B3I j9PNtqzexGudAHuoO+qkFpTGo5a9mGUklfz5auN4QH4v/ELMp5R6vqVNYokR7SAQiSt3 iesaeuDw5G0BMflpQYYIwjXHZZwVUQpbO+BHE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <e2ee45f3-17c7-405a-a076-9b6d9d70a13e@default>
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: <49C365C1.6050203@xxxxxxxxxxxxx> <e2ee45f3-17c7-405a-a076-9b6d9d70a13e@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, Mar 20, 2009 at 2:40 PM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
> Interesting.  And non-intuitive.  I think you are saying
> that, at least theoretically (and using your ABCD, not
> my ABC below), A is always faster than
> (B | C), and (B | C) is always faster than D.  Taking into
> account the fact that the TLB size is fixed (I think),
> C will always be faster than B and never slower than D.

Changing the p2m of course won't help in the shadow pagetables case. :/
The 'good' news is that I *think* after recent measures that in
current shadow pagetables a better utilization of the TLB entries
(e.g. setting the PSE bits in the shadows, which is possible after the
2Mb p2m entries) per se doesn't affects performance *at all*.

I will soon have a very small patch that would, if my current analysis
is correct, improve performance in applications using 2Mb pages
without setting PSE in shadows. I'll just need some people helping me
with testing it on these kind of applications.


It was a type of people I did not know, I found them very strange and
they did not inspire confidence at all. Later I learned that I had been
introduced to electronic engineers.
                                                  E. W. Dijkstra

Xen-devel mailing list