RE: [RFC][PATCH] 0/9 Populate-on-demand memory

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

> > The consequence for a no-swap-disk is application failures
> > and the consequence even if a swap disk IS configured is temporarily
> > very poor performance.
> 
> I don't think this is particular to the PoD patches, or even
> ballooning per se.  A swap disk would be required any time you boot
> with a small amount of memory, whether it could be increased or not.
>
> But you're right, in that this differs from a typical operating
> system's "demang-paging" mechanism, where the goal is to give a
> process only the memory it actually needs, so you can use it for other
> processes.  You're still allocating a fixed amount of memory to a
> guest at start-up.  The un-populated memory is not available to use by
> other VMs, and allocating more memory is a (relatively) slow process.
> I guess a brief note pointing out the difference between "populate on
> demand" and "allocate on demand" would be useful.

Yes, its just that with your fix, Windows VM users are much more
likely to use memory overcommit and will need to be "trained" to
always configure a swap disk to ensure bad things don't happen.
And this swap disk had better be on a network-based medium or
live migration won't work.
 
> > So this won't work for any domain that does start-of-day
> > scrubbing with a non-zero value?  I suppose that's OK.
> 
> Not if the scrubber might win the race against the balloon driver. :-)
>  If this really becomes an issue, it should be straightforward to add
> functionality to handle it.  It just requires having a simple way of
> specifying what "scrubbed" pages look like, an extra p2m type for "PoD
> scrubbed" (rather than PoD zero, the default), and how to change from
> scrubbed <-> zero.
> 
> Did you have a particular system in mind?

No, I had just given some limited thought to this problem previously,
had considered the idea of sharing a zero page for the Windows
start-of-day scrubbing problem, but didn't know if the scrubbing
always only used zeroes.  If it does, great!  I was worried that
something like a secure version of Windows might use some other random
bit pattern, but I'll bet Windows elsewhere assumes that all pages
start as zero-filled and is thus dependent on start-of-day ZERO
scrubbing, so I'll bet your approach will always work.