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


[Xen-devel] Re: [PATCH] Add hypercall to mark superpages to improve perf

To: Dave McCracken <dcm@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Add hypercall to mark superpages to improve performance
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Sun, 2 May 2010 16:54:56 -0700
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen Developers List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 02 May 2010 16:56:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201005021634.56315.dcm@xxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrqP4Trj5SNGNzgTO6NvnO23nvajwAE1i3/
Thread-topic: [PATCH] Add hypercall to mark superpages to improve performance
User-agent: Microsoft-Entourage/
On 02/05/2010 14:34, "Dave McCracken" <dcm@xxxxxxxx> wrote:

> One outstanding issue I see is how to handle readonly mappings.  If we follow
> the model of regular page typecount, readonly mappings of superpages would not
> conflict with the "conflicts with superpage" type.  This means a subsequent
> attempt to change it to a read/write mapping could fail, just like with a
> regular page.  Or we could count all mappings of superpages as if they were
> read/write.

I'd keep an extra refcount in superpage_info to track read-only mappings (or
all superpage mappings, as page->count_info does for 4kB mappings). It's
trivial extra space and avoids having unexpected extra restrictions on
read-only superpage mappings.

> What are your thoughts?  It seems fairly simple and elegant to me, and at this
> point I don't see any big holes in it.

It does mean that creating/destroying pagetable pages causes an extra locked
read-modify-write cycle on a non-local cacheline (superpage_info refcount).
Would this be significant? Not sure. I guess we'd only be doing it for
guests with the superpage capability configured, and we could do some
performance comparisons with the capability enabled/disabled. I think
overall I quite like your suggestion.

 -- Keir

Xen-devel mailing list