From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions Date: Tue, 12 Feb 2013 11:18:49 -0500 Message-ID: <20130212161849.GH3016@phenom.dumpdata.com> References: <1357635807.12649.94.camel@dagon.hellion.org.uk> <8c937ac1-3b79-4ca4-9637-f563f7d8eca8@default> <1357728078.7989.219.camel@zakaz.uk.xensource.com> <5692967d-11f4-4c44-be68-76a99f4ee482@default> <50F42827.60507@eu.citrix.com> <9be877bb-d38b-40c7-bae7-b66497f11abf@default> <50F45FBA.3000508@eu.citrix.com> <1358943520.17440.38.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1358943520.17440.38.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Dan Magenheimer , "Keir (Xen.org)" , George Dunlap , Andres Lagar-Cavilla , "Tim (Xen.org)" , "xen-devel@lists.xen.org" , Konrad Rzeszutek Wilk , Jan Beulich , Ian Jackson List-Id: xen-devel@lists.xenproject.org On Wed, Jan 23, 2013 at 12:18:40PM +0000, Ian Campbell wrote: > On Mon, 2013-01-14 at 23:14 +0000, Dan Magenheimer wrote: > > For the public record, I _partially_ believe #3. I would restate it > > as: You (and others with the same point-of-view) have a very fixed > > idea of how memory-management should work in the Xen stack. This > > idea is not really implemented, AFAICT you haven't thought through > > the policy issues, and you haven't yet realized the challenges > > I believe it will present in the context of Oracle's dynamic model > > (since AFAIK you have not understood tmem and selfballooning though > > it is all open source upstream in Xen and Linux). > > Putting aside any bias or fixed mindedness the maintainers are not > especially happy with the proposed fix, even within the constraints of > the dynamic model. (It omits to cover various use cases and I think > strikes many as something of a sticking plaster). Could you excuse my ignorance of idioms and explain what 'sticking plaster' is in this context? Is it akin to 'duct-tape'? > > Given that I've been trying to suggest an alternative solution which > works within the constraints of you model and happens to have the nice > property of not requiring hypervisor changes. I genuinely think there is > a workable solution to your problem in there, although you are correct > that it mostly just an idea right now. This is mid.gmane.org/mid.gmane.org/20130121102923.GA72616@ocelot.phlegethon.org right? Dan had some questions about it and some clarifications about the premises of it. And in: http://mid.gmane.org/1357743524.7989.266.camel@zakaz.uk.xensource.com you mentioned that you will take a look back at it. Perhaps I am missing an email? > > That said the best suggestion for a solution I've seen so far was Tim's > suggestion that tmem be more tightly integrated with memory allocation > as another step towards the "memory scheduler" idea. So I wouldn't Is this the mid.gmane.org/20130121102923.GA72616@ocelot.phlegethon.org ? > bother pursuing the maxmem approach further unless the tmem-integration > idea doesn't pan out for some reason. Maxmem is which one? Is that the one that Xapi is using wherein the d->max_pages is set via the XEN_DOMCTL_max_mem hypercall? > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >