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 10:54 +0000, Olaf Hering wrote:
> On Mon, Mar 12, Ian Campbell wrote:
> > > > > tools, nice to have:
> > > > > [...]
> > > > >       * Configure/control paging via xl/libxl (Olaf Herring, lots of
> > > > >         discussion around interface)
> > > > 
> > > > Is this a reasonable summary of the state of the paging/sharing &
> > > > friends world for 4.2? Is there anything missing?
> > > 
> > > There are indeed alot of ideas regarding the interface, and its
> > > currently not clear to me if there is an agreement yet. Was there any
> > > outcome where to proceed?
> > 
> > I've mostly swapped it out while I was away so I need to go back to the
> > thread and figure out where we got to. I don't think we had discussed
> > the libxl interface, only xl. I think the proposal Andres made sense in
> > this respect when he described it to me (although I've not read the mail
> > yet).
> 
> So is this something we should work out for the 4.2 release?

I think it was on the nice to have list which I think is an accurate
place.

> If I understand it right, there should be a .cfg option
> mem_policy=<string>, where string could be "paging" or "balloon".

The string names the "actor" which will implement the policy (so perhaps
the cfg option name should be "mem_actor="? Seems clumsy). So the
default for xl would be "xl". An existing alternative actor would be
"squeezed" which should cause the system to use XCP's squeezed (this
would require updates to squeezed to actually use these interfaces). You
can imagine that others might want to implement other more complex
actors in the future (e.g. which combine sharing, paging, and tmem in an
interesting way).

The "xl" actor should implement the "paging=auto" balloon, delay, then
page mechanism (or just ballooning for PV guests) we discussed
previously (I think most recent proposal was in
<1330078304.8557.157.camel@xxxxxxxxxxxxxxxxxxxxxx>),
iff /local/domain/X/memory-policy/actor == "xl". We can ignore sharing
with this new scheme and leave it to whomever implements the sharing
memory policy actor.

I expect that the xl daemon would be the entity which actually
implements this actor for the guest which it is monitoring. We should
probably supply a helpful libxl event triggered when the policy
parameters (under /local/domain/X/memory-policy/) change.

I suppose there is also scope for an actor specific arbitrary string,
e.g. mem_policy_args or so.

I think that in the normal case we would not support mixing and matching
actors on a system, so in the case of xl I would expect to normally find
mem_policy in /etc/xen/xl.conf rather than in the guest configuration
file. It is reasonable for an actor implementation to consist either a
per-host daemon (like squeezed) or a per-domain daemon (like xl).

libxl_set_memory_target would be changed to set the
"/local/domain/X/memory-policy/target", this is used by "xl mem-set".

libxl should also expose methods to set the balloon and paging targets,
these would be used by the code in xl which implements the "xl" policy
described above.

> In case of balloon the target value would be whats in use now
> (memory+maxmem). In case of paging these values could be reused in the
> same way, just that maxmem+memory would not create a PoD guest.
> If mem_policy= is not given it will default to balloon to retain current
> behaviour.

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.

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?

Thoughts?

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?

Ian.



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