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] GPLPV memory ballooning and x32

To: "Paul Durrant" <Paul.Durrant@xxxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxxx>, "Aravindh Puthiyaparambil" <aravindh@xxxxxxxxxx>, Pasi Kärkkäinen <pasik@xxxxxx>
Subject: RE: [Xen-devel] GPLPV memory ballooning and x32
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Tue, 25 May 2010 20:04:10 +1000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 25 May 2010 03:05:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <291EDFCB1E9E224A99088639C47620227A46A71CF2@xxxxxxxxxxxxxxxxxxxxxxxxx>
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: <D83C13F0C853364EB226DBEE584BBE614DAB25F830@xxxxxxxxxxxxxxxxxxxxxxxxxx><C8213256.150CE%keir.fraser@xxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01996B09@trantor> <291EDFCB1E9E224A99088639C47620227A46A71CF2@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acr7Eln9C5XzuBeXS+KSV/Yrq0icfAAdxdPgABNdRaMAAE4W8AAEoe8gAAFzWvA=
Thread-topic: [Xen-devel] GPLPV memory ballooning and x32
> The position of invalid entries in the P2M are not important. IIRC all entries
> start PoD. If Windows can allocate without zeroing the memory (for which
> you'll need MmAllocatePagesForMdlEx, so 2k3 SP1+) then the entry will remain
> PoD until the decrease reservation makes it invalid. Otherwise, there will be
> a populate followed by an immediate invalidation, which will clearly slow
> things down a little but is not disastrous. Providing the total number of
> populated pages does not reach the dynamic-max threshold, everything is fine.

That was my next question. So decrease_reservation on a unpopulated PoD page is 
okay. I think I have all the pieces of the puzzle then, and I don't think I 
have to do anything different to what I'm doing now (except maybe some 
accounting changes), which is always nice :)

> The only caveat with Windows is that it is good to balloon early because
> allocating enough guest pages to fulfill a balloon-down gets harder as the
> myriad of Windows kernel modules can quite aggressively land-grab in my
> experience.

It's also pretty good at letting go of memory when under pressure. My balloon 
down runs in a loop with a timer on it - if it fails to get enough memory to 
balloon down it just waits a bit (1 second I think) then tries to grab some 
more, and there is usually enough available by then. Unless you are getting 
silly with the amount of ballooning then it's normally straight forward. My 
test 2K3 DomU starts at 512MB and I can balloon it down to about 300MB shortly 
after boot before MmAllocatePagesForMdlEx starts failing to allocate memory, 
and then another 20 seconds of going around the loop before I get down to about 
200MB. I haven't tried to go lower than that but I suspect it wouldn't end well 
if I tried :)

My Balloon up is the same - it just keeps trying to get memory until Xen has 
some free. I should probably put a backoff in there though.

Thanks for the info!


Xen-devel mailing list