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

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: RFC: Doing a superpage zero-sweep on decrease_reservation
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Wed, 9 Mar 2011 14:23:35 +0000
Cc: James, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Harper <james.harper@xxxxxxxxxxxxxxxx>
Delivery-date: Wed, 09 Mar 2011 06:24:19 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=bTU8pM9Ac7-jimjFXZZazPN3_a5Dkc+1PfEqP@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: <AANLkTi=bTU8pM9Ac7-jimjFXZZazPN3_a5Dkc+1PfEqP@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)

At 13:47 +0000 on 09 Mar (1299678468), George Dunlap wrote:
> 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.

Do you think ballooned-out pages are likely to be in 2MB chunks of
zeroed memory?  Apart from avoiding shattering and re-gathering a 2MB
p2m range (which is nice, but proabbly not the perf bottleneck for PoD
right now), this is a change from scanning arbitrary memory when we run
out to scanning memory around balloon sites as we go.

If this is likely to have a high hit rate, great.  If not, it might be
(overall) worse because we waste time scanning as we balloon and have to
do the full scan later anyway.

> 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.

I'm not so keen on that - AFAICS once we've passed #pod-entries ==
#pod-pages, we shouldn't be doing any expensive work for PoD.  We might
want to think about defragging HVM guests independently of the PoD
stuff, though. 



Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Xen-devel mailing list