Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> Subject: Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of 
> existing) hypercall
> 
> On Wed, 2012-11-14 at 23:55 +0000, Dan Magenheimer wrote:
> >
> > Note 1: Tim: I'm thinking this may resolve your concern that
> > the claim mechanism must be more complicated to handle
> > restricted memory allocations and order>0 allocations.
> > The proposed claim mechanism only guarantees a quantity of
> > order==0 pages; if restricted allocations are required, these
> > are done first by the toolstack, and followed by the claim.
> > Order>0 allocations still work if memory is not fragmented,
> > but the claim mechanism doesn't guarantee anything but
> > a quantity of order==0 pages.
> 
> How does this interact with the feature which lets you create PV guests
> using only superpages? I believe is something Oracle added and still
> maintains (Dave added to the CC).
> 
> Also doesn't this fail to make any sort of guarantee if you are building
> a 32 bit PV guest, since they require memory under a certain host
> address limit (160GB IIRC)?
> 
> Basically neither of those cases benefit from this hypercall at all? I
> don't know what the usecase for the superpage PV guests is (but I
> suppose it is important to Oracle, at least). The 32 bit PV guest use
> case is still a pretty significant one which I think ought to be
> handled, otherwise any system built on top of this functionality will
> only work reliably in a subset of cases.

The claim mechanism will not benefit PV superpages.  IIUC, the
design of the PV superpages will cause a domain launch to fail
if it requests 10000 superpages but Xen can only successfully
allocate 9999.  That's already very fragile.  Since the only
way currently to find out if there are 10000 superpages available
is to start allocating them, claim can't really help.

For 32 bit PV guests, note that a claim does NOT have to be
staked prior to any allocation.  So if a toolstack needs
to enforce that some portion of allocated memory is under
a host address limit, it can (attempt to) allocate those pages,
then stake a claim for the rest.  Or just not use the claim
mechanism at all.

Dan

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