[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall
> >> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |