From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: boris.ostrovsky@oracle.com, stefano.stabellini@eu.citrix.com,
Wei Liu <wei.liu2@citrix.com>,
david.vrabel@citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH RFC 00/10] Xen balloon page compaction support
Date: Fri, 17 Oct 2014 13:35:46 +0100 [thread overview]
Message-ID: <54410D22.2000403@citrix.com> (raw)
In-Reply-To: <1413451617.2012.7.camel@citrix.com>
On 16/10/14 10:26, Ian Campbell wrote:
> On Wed, 2014-10-15 at 18:14 +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,
> That's fine. This work still improves things for plenty of other
> domains.
>
> I suspect with a suitable amount of cunning it might be possible to do
> this for domains with passthrough using smmu. Whether it is worth the
> time and effort (since I certain concede it won't be easy) I don't know.
x86 IOMMUs do not support restarable faults, and given the timing
constraints in the PCI spec, there is no obvious way to gain support
like this.
As a result, it is impossible for Xen to move a page, while maintaining
DMA read and write coherency for devices.
~Andrew
prev parent reply other threads:[~2014-10-17 12:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 15:54 [PATCH RFC 00/10] Xen balloon page compaction support Wei Liu
2014-10-15 15:54 ` [PATCH RFC 01/10] balloon_compaction: don't BUG() when it is not necessary Wei Liu
2014-10-15 15:54 ` [PATCH RFC 02/10] xen/balloon: fix code comment for free_xenballooned_pages Wei Liu
2014-10-15 15:54 ` [PATCH RFC 03/10] xen/balloon: consolidate data structures Wei Liu
2014-10-15 15:54 ` [PATCH RFC 04/10] xen/balloon: factor out function to update balloon stats Wei Liu
2014-10-15 15:54 ` [PATCH RFC 05/10] xen/balloon: rework increase_reservation Wei Liu
2014-10-15 15:54 ` [PATCH RFC 06/10] xen/balloon: make use of generic balloon driver Wei Liu
2014-10-15 15:54 ` [PATCH RFC 07/10] xen/balloon: factor out some helper functions Wei Liu
2014-10-15 15:54 ` [PATCH RFC 08/10] xen/balloon: implement migratepage Wei Liu
2014-10-15 16:16 ` David Vrabel
2014-10-16 9:28 ` Ian Campbell
2014-10-15 15:54 ` [PATCH RFC 09/10] balloon: BALLOON_COMPACTION now depends on XEN_BALLOON Wei Liu
2014-10-15 15:54 ` [PATCH RFC 10/10] XXX: balloon bitmap and sysrq key to dump bitmap Wei Liu
2014-10-15 16:25 ` [PATCH RFC 00/10] Xen balloon page compaction support David Vrabel
2014-10-15 16:30 ` Wei Liu
2014-10-16 9:31 ` David Vrabel
2014-10-15 16:54 ` Andrew Cooper
2014-10-15 17:00 ` Wei Liu
2014-10-15 17:14 ` Andrew Cooper
2014-10-16 9:12 ` Wei Liu
2014-10-16 9:26 ` Ian Campbell
2014-10-17 12:35 ` Andrew Cooper [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54410D22.2000403@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.