[Xen-devel] RFC: Doing a superpage zero-sweep on decrease_reservation

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

I'm going through the populate-on-demand patches that we've had in our
XenServer patchqueue and trying to figure out what he best thing is to
do.

One of the things we implemented was a hypercall that would allow the
tools to initiate a zero-page sweep.  The idea for this actually was
to try to help keep contiguous superpages if possible.  Asking Windows
for 2meg pages couldn't be made to work properly (Paul said, you can
ask Windows, but it just wouldn't give any). When ballooning down, the
balloon driver first calls for a zero-page sweep, hoping Xen will find
big contiguous zero superpages it can reclaim; then as the balloon
driver returns individual pages, eventually it will end up filling in
a lot of whole superpages anyway.

The problem with this is that for machines with very large memory,
this hypercall can take a long time; and if the VM has already been
running for a while, it's likely that a significant portion of the
space *won't* be zero.

It occured to me, it might be simpler if we check for a zero superpage
when doing a decrease_reservation call instead.  We'd only do a sweep
if the p2m entry is currently a superpage.  If that's the case, we
sweep the superpage containing that mfn and nothing else.  If the
whole superpage isn't zero, we'll shatter the superpage in the p2m
tables, so that even if we get an mfn from the same page again, we
won't scan it.

I was going to say, "scan only if the number of p2m entries is higher
than the number of entries in the cache".  But it occurred to me, it
might not be a bad idea to scan for zero pages in any case  -- so that
we can consolidate even after the guest has been running for a while.

Thoughts?
 -George

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