|
xen-devel
Re: [Xen-devel] [RFC][PATCH]Large Page Support for HAP
|
To: |
Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [RFC][PATCH]Large Page Support for HAP |
|
From: |
"Stephen C. Tweedie" <sct@xxxxxxxxxx> |
|
Date: |
Tue, 20 Nov 2007 11:56:26 +0000 |
|
Cc: |
Stephen Tweedie <sct@xxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, "Huang2, Wei" <Wei.Huang2@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx> |
|
Delivery-date: |
Tue, 20 Nov 2007 03:57:16 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<C3686702.106F9%Keir.Fraser@xxxxxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
Organization: |
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 |
|
References: |
<C3686702.106F9%Keir.Fraser@xxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Hi,
On Tue, 2007-11-20 at 10:27 +0000, Keir Fraser wrote:
> An HVM guest always thinks it has big contiguous chunks of RAM. The
> superpage mappings get shattered invisibly by the HV in the shadow page
> tables only if 2M/4M allocations were not actually possible. This shattering
> happens unconditionally right now, so what's being proposed is a net benefit
> to HVM guests.
If an HVM guest asks for a bigpage allocation and silently fails to get
it, then that is a net lose for the guest --- the guest takes all of the
pain for none of the benefits of bigpage.
So, you may be better off not offering bigpages at all than offering
them on a best-effort basis; at least that way the guest knows for sure
what resources it has available.
I'm not against supporting bigpages. But if there's no way for a guest
to know for sure if it has actually _got_ big pages, then I'm not sure
how much use it is.
Note that this probably works fine for controlled benchmark scenarios
where you're running a guest on a single carefully-configured host with
matched bigpage reservations. But in general, you need bigpages to
continue to work predictably over save/restore, migrate, balloon etc.
else they become a net cost, not a net gain, to the guest.
--Stephen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home