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] RFC: Doing a superpage zero-sweep on decrease_reservation

To: Keir Fraser <keir@xxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: [Xen-devel] RFC: Doing a superpage zero-sweep on decrease_reservation
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 9 Mar 2011 13:47:48 +0000
Cc: Paul Durrant <paul.durrant@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, James Harper <james.harper@xxxxxxxxxxxxxxxx>
Delivery-date: Wed, 09 Mar 2011 05:48:22 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=PLtBZWs89SjeChL+k+vWzCkEgtNwJMqwhrwFwbRiQ3U=; b=I6POjMWPWTDoVNj6CGuyhaS2jAmUqRNNOweO9pprGiOR66YYcCAcdxJeZXS9ldIx4t y06k8g1ZzD+m1VGaPQ7H0zGF58mYlvWj/mEtoX5y1mPiHiilpfX/te6DZV14SjsFrQzH PNT9maB1D8rEp8HMutNu05tP6vwyWcgjh7G8c=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=Z9H6utST83UYZ6bXDu1KL3FygQ0QqABN4UOOsNFElpavsGA0SKzG2Gg+wCCTvh9k7A PHqZFU5NLu/WNiSDCnT0Wp8NGs+4azWTk0umkkHuu4ufJqgu/YqIiGyvocmsWGPnE+fk WhlXZXi4dl+Tlv9qcwut0KA0E0Fx9pYuuagDg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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
I'm going through the populate-on-demand patches that we've had in our
XenServer patchqueue and trying to figure out what he best thing is to

One of the things we implemented was a hypercall that would allow the
tools to initiate a zero-page sweep.  The idea for this actually was
to try to help keep contiguous superpages if possible.  Asking Windows
for 2meg pages couldn't be made to work properly (Paul said, you can
ask Windows, but it just wouldn't give any). When ballooning down, the
balloon driver first calls for a zero-page sweep, hoping Xen will find
big contiguous zero superpages it can reclaim; then as the balloon
driver returns individual pages, eventually it will end up filling in
a lot of whole superpages anyway.

The problem with this is that for machines with very large memory,
this hypercall can take a long time; and if the VM has already been
running for a while, it's likely that a significant portion of the
space *won't* be zero.

It occured to me, it might be simpler if we check for a zero superpage
when doing a decrease_reservation call instead.  We'd only do a sweep
if the p2m entry is currently a superpage.  If that's the case, we
sweep the superpage containing that mfn and nothing else.  If the
whole superpage isn't zero, we'll shatter the superpage in the p2m
tables, so that even if we get an mfn from the same page again, we
won't scan it.

I was going to say, "scan only if the number of p2m entries is higher
than the number of entries in the cache".  But it occurred to me, it
might not be a bad idea to scan for zero pages in any case  -- so that
we can consolidate even after the guest has been running for a while.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>