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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

~Andrew


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