RE: Xen balloon driver discuss

[Dan Magenheimer <dan.magenheimer@oracle.com>]

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

Dan