Re: [Xen-devel] [PATCH RFC 00/10] Xen balloon page compaction support

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Oct 15, 2014 at 06:14:56PM +0100, Andrew Cooper wrote:
> On 15/10/14 18:00, Wei Liu wrote:
> > On Wed, Oct 15, 2014 at 05:54:24PM +0100, Andrew Cooper wrote:
> >> On 15/10/14 16:54, Wei Liu wrote:
> >>> Hi all
> >>>
> >>> This is a prototype to make Xen balloon driver work with balloon page
> >>> compaction. The goal is to reduce guest physical address space 
> >>> fragmentation
> >>> introduced by balloon pages. Having guest physical address space as 
> >>> contiguous
> >>> as possible is generally useful (because guest can have higher order 
> >>> pages), and
> >>> it should also help improve HVM performance (provided that guest kernel 
> >>> knows
> >>> how to use huge pages -- Linux has hugetlbfs and transparent huge page).
> >> After you have defragmented guest physical memory, does Linux use
> >> 2MB/1GB superpages more readily?
> >>
> > That's completely up to the guest. Having contiguous guest physical
> > address space is prerequisite.
> >
> >> On what basis do you think this will improve HVM performance?  The HAP
> >> tables still remain fragmented after ballooning.
> >>
> > That's the other side of this problem and orthogonal to this patch
> > series. It should be fixed separately on the hypervisor side, presumably
> > with similar mechanism to coalesce HAP table in hypervisor.
> 
> You can't rearrange the memory of any domain with passthrough, or any
> subregion which is mapped by another domain.  Even if the underlying
> pages are in order, you can't coalesce 4K pages to 2M pages for any
> region containing a grant.
> 

But these cases don't invalidate my point, do they? We can still
coalesce regions that can be coalesced.

> By far the best solution for both guest and hypervisor is for Xen to do
> its utmost to allocate superpages to start with, and then for the guest

This is what it is now, as I understand it.

> not to shoot holes in its physical address space in the first place.
> 
> This would involve intelligently choosing which pages to balloon/grant
> first, rather than blindly choosing the first free page.
> 

That would require modification to Linux memory allocator which is very
unlikely to get upstreamed.

Wei.

> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel