Re: Analysis of using balloon page compaction in Xen balloon driver

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2014-10-17 at 13:30 +0100, Andrew Cooper wrote:
> Step 3 is an expensive (especially for Xen, which has far more important
> things to be doing with its time) and which is self-perpetuating because
> of the balloon driver reshattering pages.
> 
> Several factors contribute to shattering host pages.  The ones which
> come to mind are:
> * Differing cacheability from MTRRs
> * Mapping a foreign grant into ones own physical address space
> * Releasing pages back to Xen via the decrease_reservation hypercall
> 
> In addition, other factors complicate Xens ability to move pages.
> * Mappings from other domains (Qemu, PV backends, etc) will pin mfns in
> place
> * Any IOMMU mappings will pin all (mapped) mfns in place.
> 
> As a result, by far the most efficient way of prevent superpage
> fragmentation is to not shattering them in the first place.  This can be
> done by changing the balloon driver in the guest to co-locate all pages
> it decides to balloon, rather than taking individual pages at random
> from the main memory pools.

Right, a necessary part of this work is to try and balloon (both up and
down) in correctly aligned 2M increments, by allocating 2M pages to free
back to Xen.

All the coalescing stuff is a bit secondary (but still necessary) and is
there to mitigate the case when a guest can't find a 2M page to allocate
(so has done some 4K ops instead, in order to meet the targets) and/or
to increase the probability it will be able to allocate one.

Ian.