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

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

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

Andres

> 
> Olaf might have been intending to look into this (I can't quite remember
> where we left it)
> 
> Ian.
> 
> 


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