Re: [Xen-devel] Paging/sharing in 4.2 (Was: Re: 4.2 TODO update)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2012-03-13 at 13:36 +0000, Olaf Hering wrote:
> On Tue, Mar 13, Ian Campbell wrote:

> > I think the libxl default should be to immediately set the balloon
> > target. This would retain the historical behaviour for toolstacks which
> > don't say differently and would also work as expected for dom0 (which
> > may not have the necessary /local/domain/X/memory-policy/actor key).
> > 
> > The default set by xl should be "xl" or whatever is provided in the
> > config.
> > 
> > The other option for the default provided by libxl will be to do nothing
> > I don't think that is as helpful/useful as a default though.
> 
> I think that a default of "none" would change behaviour. So having "xl"
> as default which makes the guests behave like before will remove
> surprises during upgrade to 4.2.

The default for _libxl_ cannot be "xl", since the toolstack may not be
xl.

I think my first proposal for libxl's default makes sense, that is that
libxl should set things directly unless
libxl_domain_set_memory_policy_actor (or whatever the function ends up
being called) has been called.

> > There should probably be an option to set the actor to "none", meaning
> > that the toolstack is taking direct responsibility for this domains
> > memory targets. This would be used when "xl mem-paging-set domain
> > manual" was called allowing xl to implement the "xl mem-paging-set
> > domain N" in manual mode as described in
> > <1330078304.8557.157.camel@xxxxxxxxxxxxxxxxxxxxxx>. Or maybe this
> > corresponds to using "xl-auto" and "xl-manual" as the policies?
> 
> I'm not sure about the manual mode. If one calls mem-paging-set or
> mem-balloon-set to change the target value, why not do it right away?

You would also need to change the actor to something which would not
conflict with such a manual change.

> > Thoughts?
> 
> Thanks for the writeup, Ian!
> 
> > I suppose I ought to go back to
> > <1330078304.8557.157.camel@xxxxxxxxxxxxxxxxxxxxxx> and update the
> > descriptions to account for this "actor" scheme and also flesh out the
> > underlying libxl interface (which we previously have ignored in that
> > discussion). Would that be useful?
> 
> Yes, an updated description/proposal is useful IMHO.

I'll try and get to it in the next couple of days.

Ian.


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