Re: [Xen-devel] [RFC][PATCH] 0/9 Populate-on-demand memory

["George Dunlap" <George.Dunlap@xxxxxxxxxxxxx>]

On Wed, Dec 24, 2008 at 2:32 PM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
> 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.

You mean they may be much more likely to under-provision memory to
their VMs, booting with (say) 64M on the assumption that they can
balloon it up to 512M if they want to?  That seems rather unlikely to
me... if they're not likely to start a Windows VM with 64M normally,
why would they be more likely to start with 64M now?  I'd've thought
it would be likely to go the other way: if they normally boot a guest
with 256M, they can now start with maxmem=1G and memory=256M, and
balloon it up if they want.

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

AIUI, Windows has two "free page" lists: zeroed, and dirty.  The
scrubber moves pages from the dirty list to the zero list.  Most of
the page allocation interfaces promise zeroed pages, as would mapping
"anonymous" process memory (not sure the Windows term for that).  So
the most useful state for an un-allocated page to be in is zero,
because there's a high probability that it will have to be zeroed
before it's used anyway.

At any rate, we can cross that bridge if we ever come to it. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel