Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: George Dunlap [mailto:George.Dunlap@xxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Tue, Oct 16, 2012 at 6:51 PM, Dan Magenheimer
> <dan.magenheimer@xxxxxxxxxx> wrote:
> >
> > If you reread my last response with the assumption in mind:
> >
> >   "tmem == an instance of a memory scheduler == grand vision"
> >
> > then does the discussion of the "memory reservation" hypercall
> > make more sense?
> 
> Sort of. :-) Unfortunately, I think it shows a bit of confusion, which
> is perhaps why it was hard to understand.
>    :
> I'm not fundamentally opposed to the idea of an "allocate memory to a
> VM" hypercall; but the arguments adduced to support this seem
> hopelessly confused, which does not bode well for the usefulness or
> maintainability of such a hypercall.

Hi George --

Now I think I have a better idea as to why you are not understanding
and why you think this is confusing!!!

It seems we are not only speaking different languages but are
from completely different planets!  I.e. our world views are
very very different.

You have a very very static/partitioned/restrictive/controlled view
of how memory should be managed in a virtual environment.

I have a very very dynamic view of how memory should be managed in
a virtual environment.

Tmem -- and the ability to change guest kernels to cooperate in dynamic
memory management -- very obviously drives my world view, but my view
reveals subtle deficiencies in your world view.  Xapi and the constraints
it lives under (i.e. requirement for proprietary HVM guest kernels)
and the existing Xapi memory controller model seems good enough for
you, so your view makes my need for handling subtle dynamic corner
cases appear that I must have some secret fantastical "grand design"
in mind.

> Any system that follows the rules I've set above won't have to worry
> about free memory disappearing half-way through domain creation.

Agreed.  My claim is that: (1) tmem can't possibly follow your rules
as it would decrease its value/performance by several orders of
magnitude; (2) page-unsharing/swapping can't possibly follow your rules
because the corner cases it must deal with are urgent, frequent, and
unpredictable; (3) a "cloud orchestration layer" can't follow your rules
because of complexity and communication limits, unless it greatly
constrains its flexibility/automation; (4) following your
rules serializes common administration activities even for Xapi
that otherwise don't need to be serialized.

I think your rules take an overconstrained problem (managing memory
for multiple VMs) and add more constraints.  While IMHO tmem takes away
constraints.

That's why I brought up CPU schedulers.  I know you are an expert
in CPU scheduling, and you would never apply similar rules to
CPU scheduling that you want to apply to "memory scheduling".
E.g. you would never require the toolstack to be in the critical
path for every VCPU->CPU reassignment.

And so I have to try to solve a problem that you don't have (or IMHO
that you will likely have in the future but don't admit to yet ;-)
And I think the "reservation" hypercall will solve that problem.

> In all of this discussion, I don't see any reason to bring up tmem at
> all (except to note the reason why a VM may balloon down).  It's just
> another area to which memory can be allocated (along with Xen or a
> domain).  It also should not be allowed to allocate free Xen memory to
> itself without being specifically instructed by the toolstack, so it can't
> cause the problem you're talking about.

This is all very wrong.  It's clear you don't understand why tmem exists,
how it works, and what its value is/can be in the cloud.  I'll take some
of the blame for that because I've had to spend so much time in
Linux-kernel land in the last couple of years.

But if you want to try a different world view, and understand tmem,
let me know ;-)  I don't mean to be immodest, but I truly believe it
is the first significant advance in managing RAM in a virtual
environment in ten years (since Waldspurger).

Dan


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