Re: Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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
>