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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 19.11.12 at 21:53, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
>> Subject: Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of 
> existing) hypercall
> 
> Hi Ian --
> 
>> 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:
>> > >
>> > > 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.
> 
> Because of the nature of the buddy allocator (i.e. 4MB chunks are
> kept separately from 2MB chunks even though a 4MB page contains
> two 2MB pages), I don't think this is trivial.

This ought to be as simple as adding respective accounting
when
- splitting a chunk in alloc_heap_pages(), crossing the super page
  size boundary, and
- merging chunks in free_heap_pages(), crossing the super page
  size boundary.

Jan


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