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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-11-15 at 19:15 +0000, Dan Magenheimer wrote:
> > 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.

Well, you could always account the number of free superpages in the
system, which would allow you to cover this case too.

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

For 32 bit PV guests this is *all* of the pages needed to build any 32
bit PV guest.

> Or just not use the claim mechanism at all.

So your use case has no requirement to be able to start 32 bit domains?
Or whatever requirement you have the leads to the claim mechanism
somehow doesn't apply to those sorts of guests? If not then why not?

As it stands it seems that any toolstack which wants to use claim would
still have to cope with the fact that a potentially significant
proportion of guests may still fail to build even after a claim has been
successfully staked.

Even if these shortcomings are acceptable in your specific scenario I
don't see why we should be satisfied with a solution which is not more
generally applicable.

Ian.


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