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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Andres Lagar-Cavilla [mailto:andreslc@xxxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> 
> On Oct 4, 2012, at 6:17 AM, Ian Campbell wrote:
> 
> > On Thu, 2012-10-04 at 11:06 +0100, Tim Deegan wrote:
> >> but my question was really: what should xl do, in the presence of
> >> ballooning, sharing, paging and tmem, to
> >> - decide whether a VM can be started at all;
> >> - control those four systems to shuffle memory around; and
> 
> Are we talking about a per-VM control, with one or more of those sub-systems 
> colluding concurrently?
> Or are we talking about a global view, and how chunks of host memory get 
> sub-allocated? Hopefully the
> latter...
> 
> >> - resolve races sensibly to avoid small VMs deferring large ones.
> >> (AIUI, xl already has some logic to handle the case of balloon-to-fit.)
> >>
> >> The second of those three is the interesting one.  It seems to me that
> >> if the tools can't force all other actors to give up memory (and not
> >> immediately take it back) then they can't guarantee to be able to start
> >> a new VM, even with the new reservation hypercalls.
> >
> > There was a bit of discussion in the spring about this sort of thing
> > (well, three of the four), which seems to have fallen a bit by the
> > wayside^W^W^W^W^W^Wbeen deferred until 4.3 (ahem) e.g.
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg01181.html
> >
> > I'm sure there was earlier discussion which led to that, but I can't
> > seem to see it in the archives right now, perhaps I'm not looking for
> > the right Subject.
> 
> IIRC, we had a bit of that conversation during the Santa Clara hackathon. The 
> idea was to devise a
> scheme so that libxl can be told who the "actor" will be for memory 
> management, and then hand-off
> appropriately. Add xl bindings, suitable defaults, and an implementation of 
> the "balloon actor" by

Scanning through the archived message I am under the impression
that the focus is on a single server... i.e. "punt if actor is
not xl", i.e. it addressed "balloon-to-fit" and only tries to avoid
stepping on other memory overcommit technologies.  That makes it
almost orthogonal, I think, to the problem I originally raised.

But a bigger concern is that its focus on a single machine ignores
the "cloud", where Xen seems to hold an advantage.  In the cloud,
the actor is "controlling" _many_ machines.  In the problem I
originally raised, this actor (a centralized management console)
is simply looking for a server that has sufficient memory to house
a new domain, and it (or the automation/sysadmin running it) gets
unhappy if (xl running on) the server says "yes there is enough
memory" but then later says, "oops, I guess there wasn't enough
after all".

> libxl, and the end result is the ability to start domains with a memory 
> target suitably managed by
> balloon, xenpaging, tmem, foo, according to the user's wish. With no need to 
> know obscure knobs. To
> the extent that might be possible.

Am I detecting s[k|c]epticism?

If so, I too am s[k|c]eptical.

Dan

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