Re: [Xen-devel] [RFC/PATCH v6 1/2] hypervisor: XENMEM_claim_pages (subop of existing) hypercall

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.11.12 at 17:16, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Subject: Re: [RFC/PATCH v6 1/2] hypervisor: XENMEM_claim_pages (subop of 
> existing) hypercall
>> 
>> >>> On 20.11.12 at 18:04, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>> > This is patch 1of2 of a sixth cut of the patch of the proposed
>> > XENMEM_claim_pages hypercall/subop, taking into account review
>> > feedback from Jan and Keir and IanC and Matthew Daley, plus some
>> > fixes found via runtime debugging (using printk and privcmd only).
>> >
>> > v5->v6:
>> > - Fix post-inc problem [mattjd]
>> 
>> I continue to miss an expiry mechanism for claims; as said before
>> I don't think these should be held indefinitely.
> 
> Do you mean some kind of time-based expiry?
> 
> The simple use model I have in mind results in toolstack
> changes as follows:
> 
> Current:
> - call populate_physmap repeatedly to achieve mem=N memory
> - if any populate_physmap call fails, report -ENOMEM up the stack
> - memory is held until domain dies or the toolstack decreases it
> 
> Proposed:
> - call claim for mem=N amount of memory
> - if claim succeeds:
>     call populate_physmap repeatedly to achieve mem=N memory (failsafe)
>   else
>     report -ENOMEM up the stack
> - claim is held until mem=N is achieved or the domain dies or
>    the toolstack changes it to 0
> - memory is held until domain dies or the toolstack decreases it
> 
> In both cases, the memory is held "indefinitely" so I'm
> not sure I see why a claim would need a time-based expiry
> when a populate_physmap doesn't.  A claim is really just
> a "soft" version of a populate_physmap where the quantity
> of pages are (atomically) assigned to the domain but the specific
> physical pageframes are (non-atomically) assigned later.
> 
> Does that make sense?

I get your point, but it seems wasteful to me to set aside perhaps
large quantities of memory for e.g. a zombie domain cleanup of
which didn't get to releasing the claim, yet.

Jan


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