Re: [Xen-devel] libxl/xl memory paging/sharing/ballooning/etc proposal.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2012-03-19 at 16:10 +0000, Ian Jackson wrote:
> Ian Campbell writes ("libxl/xl memory paging/sharing/ballooning/etc 
> proposal."):
> > I think we've roughly reached consensus on what this could look like.
> > I've combined the various aspects of the proposal into the below.
> 
> This looks reasonable to me.
> 
> > Ian J -- I've CC'd you since I propose some new uses of the events
> > subsystem (as well as being interested in your overall opinion)
> 
> That part looks OK.
> 
> I have a slight quibble with the structure of the document which is
> that it mixes up description of interface with implementation.
> 
> > libxl_domain_set_memory_policy(ctx, domid, const char *actor, const char 
> > *params):
> >         
> >         Sets the name of the "actor" which will implement memory policy
> >         for this domain by writing the name of the actor to
> >                 /libxl/X/memory-policy/actor
> >         and the params to
> >                 /libxl/X/memory-policy/actor-params
> >                         
> >         actor-params is defined per-actor. normally be a comma separated
> >         key=value list.
> > 
> >         If libxl_domain_set_memory_policy is not called for a domain
> >         then the default is considered to be "" i.e. none.
> 
> Does this mean that any actor is required to be able to undo the
> effects of any other actor ?  Eg, if I switch from paging to
> ballooning, is the paging actor required to un-balloon the domain ?

Good question. It seems unreasonable that a balloon actor need to know
about paging.

I think what we really want is some sort of "you are being disabled"
event sent to the previous actor but I'm not at all sure how that would
be represented in the xenstore interface, nor how the interlock with the
new one would work. There's also the issue of what happens if e.g. there
isn't enough memory to undo the work the pager has done.

Big ol' can-o-worms I think.

We could fudge the issue by removing this function and only exposing
this functionality via build_info. This would require a guest reboot
(or, I suppose, a migration) to change the actor. We'd probably want to
leave the ability to change the actor params in the API though.

> > libxl_domain_set_memory_target(ctx, domid, target_memkb, bool relative,
> > bool enforce):
> > 
> >         Replaces existing libxl_domain_memory_target() function.
> >                 
> >         If memory-policy/actor != "":
> >                 updates /libxl/X/memory-policy/<target,enforce>
> >         else:
> >                 behaves as libxl_domain_memory_target today, e.g. sets
> >                 balloon target in xenstore and iff enforcing then sets
> >                 maxmem -- probably this is just a call to
> >                 libxl_domain_set_balloon_target() (see below)
> 
> It should be explicitly stated that a toolstack is allowed to
> integrate the actor and target-setter functionality, in which case the
> actor is allowed to ignore the supposed target.  Ie the use of the
> target is optional.

I'm not sure what you mean (there are, confusingly, two targets in the
interface) so I'm not sure what this (presumed) flexibility buys us.

(I have a feeling this ties into the "xl-manual" discussion below)

> > XXX I think we need a DOMAIN_INTRODUCE event to allow for a system wide
> > actor. This seems like a generally useful event anyhow.
> 
> Yes.  We need also to make sure that if you ask for domain death
> events for an already-nonexistent domain you get either an error or an
> event, which I'm not sure is currently the case.

Right, that would be a bug fix to the existing stuff, right?

> 
> >         XXX if not enforcing: return ??? (not sure about this, we don't
> >         actually expose the ability to set enforcing in the xl
> >         interface)
> 
> I think we should abolish the separate "enforce" parameter and make it
> a parameter to the xl actor.  It doesn't make much sense to vary the
> setting per-update-event.
> 
> (Well really I think it should be abolished and by pretending it's
> always true, but the last N times we had this conversation people
> disagreed.)

I agree with you FWIW.

I think can say that it is up to actor policy if and how it enforces
things (configurable as desired via params) but that xl always forces
the target (like it does today). 

This still leaves the flexibility in place for those who disagree to do
what they need.

> 
> > xl low level interface
> > ----------------------
> > 
> > All of the following setters functions should error out unless actor ==
> > "xl-manual". The getter could return the current value regardless.
> > 
> > xl mem-balloon-(set|get)-target
> > xl mem-paging-(set|get)-target
> > 
> >         Set or get the relevant targets by calling the equivalent libxl
> >         function. 
> >         
> >         Enables or disables paging as necessary, i.e. target == 0 =>
> >         disable
> >         
> > NB if you call "xl mem-set" when actor == "xl-manual" then it won't do
> > anything since nothing is reacting as that actor.
> 
> Right.
> 
> > XXX We could alternatively have xl also implement an "xl-manual" actor
> > which immediately sets both ballooning and paging targets to the given
> > value. Probably a good idea?
> 
> That would be a bad algorithm because it would start thrashing to
> page-out-in-the-guest pages which have been paged-out-by-xenpaging.

Yes. It would be expected that you would use the low level
mem-{balloon,paging}-{set,get}-target functions if you set the actor to
manual. Calling mem-set in manual mode is more of a "please shoot me in
the foot thing". mem-set could print an error message if actor ==
xl-manual. Or do you have an idea for a better algorithm for the manual
case? Setting only balloon target could be one alternative.

> > XXX Maybe "xl" (the default) should be called "xl-auto" ?
> 
> I don't have an opinion about this.
> 
> But "" seems like an odd default value, so perhaps it should be
> explict "none" ?

Makes sense.

Ian.



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