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

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

On Oct 4, 2012, at 12:54 PM, Dan Magenheimer wrote:

>> 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.

Yeah, fairly orthogonal.
> 
> 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".

Big problem in itself, but not one for xen.org (yet, cart before horse). Have 
you had a look at the Openstack FilterScheduler? Plenty of room for 
contribution.

> 
>> 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.

Well, not really. Things have to coexist cleanly, to the extent feasible. 
Devising a libxl protocol to perform clean hand off if required, and to expose 
minimum complexity to the average joe, is a great idea imho.

Andres
> 
> Dan


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