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] [PATCH] PoD: Handle operations properly when domain is d

To: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] PoD: Handle operations properly when domain is dying
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Wed, 11 Nov 2009 08:53:28 -0800 (PST)
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 11 Nov 2009 08:55:09 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4AFADB5F.5090201@xxxxxxxxxxxxx>
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
> (The failure mode in this case was this:
> :
> So no new memory was being allocated; it was just being transferred 
> from  a place which hadn't been destroyed yet to a place which had.)

Sorry, I should have noted in my original reply that this
was topic drift not necessarily related to your patch.
The patch just reminded me to raise this PoD-related issue.

> WRT ballooning: the tools should be telling the balloon 
> driver what to 
> do; a well-behaved balloon driver will not allocate more 
> memory unless 
> the tools tell it to do so.  There are mechanisms in Xen available to 
> the tools to limit the amount of memory a balloon driver can allocate 
> even if it's not behaving.

Yes ideally.  I believe, in reality, guest memory utilization
varies too dynamically for the tools to be involved in every
ballooning decision (which is why tmem is useful).

Even assuming your tools do completely control ballooning

> So as long as the tools don't tell a VM to change its memory between 
> deciding there's enough memory for the new domain and 
> creating the new 
> domain, you shouldn't have any problems.

BUT, PoD is essentially doing dynamic ballooning without
notifying the tools, correct?  Unless I misunderstand, the
whole point of PoD is to not use zeroed-out-by-Windows
memory until it gets written (with non-zeroes), and the
underlying objective is that that not-yet-used memory can
be used for other purposes -- such as other domains.
In the case of PoD, the memory usage of the PoD domain
is monotonically increasing (ignoring ballooning for now)
but it is essentially growing in size dynamically without
notifying the tools.  As a result, either the tools need
to assume that a PoD domain IS using all of its memory,
or it risks making a decision based on rapidly-changing
(and thus ultimately stale/incorrect) data.

Xen-devel mailing list