Re: [Xen-devel] [RFC][PATCH]Large Page Support for HAP

["Stephen C. Tweedie" <sct@xxxxxxxxxx>]

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