[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Mon, Oct 8, 2012 at 2:02 AM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
> Tmem really is a breakthrough on memory management in a virtualized
> system.  I realize that many people are in the "if it doesn't
> work on Windows, I don't care" camp.  And others never thought
> it would make it into upstream Linux (or don't care because it isn't
> completely functional in any distros yet... other than Oracle's..
> but since all parts are now upstream, it will be soon).  But there
> probably are also many that just don't understand it... I guess I need
> to work on fixing that.  Any thoughts on how to start?

Well, I'm sorry to say this, but to start I think you need to work on
your communication.  I had read this entire thread 2 or 3 times before
writing my last response; and I have now read this e-mail half a dozen
times, and I'm still don't have a good idea what it is you're talking
about.  If I didn't respect you, I would have just given up on the 2nd

In my summary, I mentioned just 2 things: the problem of domain
creation, and the solution of a hypercall to allocate a big chunk of
memory to a domain.  You answered by saying it was a good summary.
But then you said:

> I'm just proposing an extension to the
> existing mechanism and I am quite convinced that the hypervisor must
> be involved (e.g. a new hypercall) for the extension to work properly.

Now you're talking about an extension... then you mention a "memory
scheduler" (which we don't yet have), and say:

> ...there is inadequate information from
> any VM to drive automatic memory allocation decisions and, even if
> there was, it just doesn't scale.

But you don't say where or who *could* have adequate information;
which again hints at something else which you have in mind, but you
haven't actually talked about very explicitly yet.  If you have been
trying to talk about it, and it wasn't in my summary, why didn't you
say something about it, instead of saying, "Yes that's right"?  And if
you haven't talked about it, why are you speaking as though we all
know already what you're talking about?

Furthermore, you say things like this:

> IMHO, the example you give for asking a memory controller for GiB
> of memory is equally silly.  Outside of some geek with a handful
> of VMs on a single machine, there is inadequate information from
> any VM to drive automatic memory allocation decisions and, even if
> there was, it just doesn't scale.  It doesn't scale either up, to
> many VMs across many physical machines, or down, to instantaneous
> needs of one-page-at-a-time requests for unsharing or for tmem.

What do you mean, "doesn't scale up or across"?  Why not?  Why is
there inadequate information inside dom0 for a toolstack-based memory
controller?  And if there's not enough information there, who *does*
have the information?  It's just a bunch of vague assertions with no
justification and no alternative proposed.  It doesn't bring any light
to the discussion (which is no doubt why the thread has died without

Nor does saying "see above" and "see below", when "above" and "below"
are still equally unenlightening.

Maybe your grand designs for a "memory scheduler", where memory pages
hop back and forth at millisecond quanta based on instantaneous data,
between page sharing, paging, tmem, and so on, is a good one.  But
that's not what we have now.  And that's not even what you're trying
to promote.  Instead, you're trying to push a single hypercall that
you think will be necessary for such a scheduler.

Doesn't it make sense to *first* talk about your grand vision and come
up with a reasonable plan for it, *then* propose an implementation?
If in the course of your 15-patch series introducing a "memory
scheduler", you also introduce a "reservation" hypercall, then
everyone can see exactly what it accomplishes, and actually see if
it's necessary, or if some other design would work better.

Does that make sense?

If I still haven't understood where you're coming from, then I am
sorry; but I have tried pretty hard, and I'm not the only one having
that problem.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.