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

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

>   
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Friday, November 16, 2012 3:36 AM
>> To: Dan Magenheimer
>> Cc: xen-devel@xxxxxxxxxxxxx; Konrad Wilk; ZhigangWang; Keir Fraser; TimDeegan
>> Subject: RE: [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall
>> 
>>>>> On 15.11.12 at 19:00, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>>> Similarly, but perhaps of lower priority, there is no integration
>>>> with the low-mem handling.
>>> 
>>> I'd also consider this lower priority as Olaf and Andre
>>> have argued that the claim mechanism is not needed for
>>> sharing/paging so the two mechanisms may not
>>> be used together, at least for the foreseeable future.
>>> So I plan to skip this, unless you change your mind and
>>> consider it a showstopper for acceptance.
>> 
>> Skipping for the initial implementation is likely fine, but that
>> shouldn't mean deferring the integration indefinitely. Also,
>> I see no close connection between the low-mem feature
>> and sharing/paging (apart from Andres working on both).

It's simple. Right now one can't reliably set d->max_pages to the watermark at 
which a VM's allocation is temporarily allowed to grow -- by unsharing or 
paging in. This is because of (hopefully fixable!) short-comings in the mm 
layer and its interaction with wait queues, documented elsewhere.

So the best next approach (in place) is to get a synchronous kick as watermarks 
in available memory are reached. Otherwise a host memory manager is down to 
polling.

It could be the case that once d->max_pages can be set reliably, one would not 
need the low_mem virq any further. But it's just such a useful feature at 
infinitesimal cost, that I would not want it to see it gone. And it would still 
remain useful in any scenario in which the total sum of d->max_pages exceeds 
available memory (for whatever reason).

> 
> Fair enough.
> 
> After reviewing the thread where low_mem was submitted, I have to admit
> that I am a bit baffled as to when the low_mem handling would ever be
> necessary.   I suspect it is because the author and I are approaching

Little to be baffled at, as per above explanation. And probably a good idea to 
cc the author if so.

Andres

> memory management from a completely different paradigm (per discussion
> in an earlier thread where "claim" was first proposed), so that
> is probably better left for the deferred discussion of the
> integration.
> 
> So since you (Jan) do not consider this (lack of integration with
> low_mem) a showstopper for claim, I will set myself a reminder
> to initiate a new thread about this later.
> 
> Thanks,
> Dan


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