RE: [Xen-devel] [PATCH] PoD: Handle operations properly when domain is dying

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

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

> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel