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] Xen balloon driver discuss

> One of the explicit purposes of PoD is to set aside a fixed amount of
> memory for a guest, so that no other domains / processes can claim it.
> It's guaranteed that memory, and as long as it has a working balloon
> driver, shouldn't have any issues using it properly.  Sharing it with
> other VMs would undermine this, and make it pretty much the same as the
> Xen free page list.
>   :
> It sounds like what you're advocating is *allocate*-on-demand (as
> opposed to PoD, which allocates all the memory at the beginning but
> *populates* the p2m table on demand): tell all the guests they have
> more
> memory than is available total, assuming that only some of them are
> going to try to use all of it; and allocating the memory as it's used.
> This works well for processes, but operating systems are typically
> built
> with the assumption that memory not used is memory completely wasted.
> They therefore keep disk cache pages and unused memory pages around
> "just in case", and I predict that any guest which has an active
> workload will eventually use all the memory it's been told it has, even
> if it's only actively using a small portion of it.  At that point, Xen
> will be forced to try to guess which page is the least important to
> have
> around and swap it out.

Maybe another key point about PoD is worth mentioning here (and
probably very obvious to George and possibly mentioned somewhere
else in this thread and I just missed it): The guest will *crash*
if it attempts to write to a PoD page and Xen has no real physical
page to back it.  Or alternately, the guest must be stopped
(perhaps for a long time) until Xen does have a real physical page
to back it.  Real Windows guest users won't like that, so the
memory should be pre-allocated and remain reserved for that guest.
Or the toolset/dom0 must implement host-swapping, which has all
sorts of nasty unpredictable performance issues.


Xen-devel mailing list