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

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Subject: Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate
> solutions
> 
> On Tue, 2013-01-08 at 19:41 +0000, Dan Magenheimer wrote:
> > [1] A clarification: In the Oracle model, there is only maxmem;
> > i.e. current_maxmem is always the same as lifetime_maxmem;
> 
> This is exactly what I am proposing that you change in order to
> implement something like the claim mechanism in the toolstack.
> 
> If your model is fixed in stone and cannot accommodate changes of this
> type then there isn't much point in continuing this conversation.
> 
> I think we need to agree on this before we consider the rest of your
> mail in detail, so I have snipped all that for the time being.

Agreed that it is not fixed in stone.  I should have said
"In the _current_ Oracle model" and that footnote was only for
comparison purposes.  So, please, do proceed in commenting on the
two premises I outlined.
 
> > i.e. d->max_pages is fixed for the life of the domain and
> > only d->tot_pages varies; i.e. no intelligence is required
> > in the toolstack.  AFAIK, the distinction between current_maxmem
> > and lifetime_maxmem was added for Citrix DMC support.
> 
> I don't believe Xen itself has any such concept, the distinction is
> purely internal to the toolstack and which value it chooses to push down
> to d->max_pages.

Actually I believe a change was committed to the hypervisor specifically
to accommodate this.  George mentioned it earlier in this thread...
I'll have to dig to find the specific changeset but the change allows
the toolstack to reduce d->max_pages so that it is (temporarily)
less than d->tot_pages.  Such a change would clearly be unnecessary
if current_maxmem was always the same as lifetime_maxmem.
 
> I don't know (or particularly care) what Citrix DMC does since I was not
> involved with it other than when it triggered bugs in balloon drivers.

I bring up DMC not to impugn the maintainers independence but
as I would if we were discussing an academic paper; DMC
is built on very similar concepts to the model you are proposing.
And (IMHO) DMC does not succeed in solving the memory overcommitment
problem.  Oracle has been building a different approach for memory
overcommit (selfballooning and tmem) for several years, it is
implemented in shipping Xen hypervisors and Linux kernels, and it is
in this context that we wish to ensure that any capacity allocation
mechanism, whether toolstack-based or hypervisor-based, works.

So, please, let's continue discussing the premises I outlined.

Thanks,
Dan