|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libxl/xl memory paging/sharing/ballooning/etc proposal.
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 ?
> XXX should the actor config also be part of struct
> libxl_domain_build_info? (I expect so)
Certainly.
> 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.
> 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.
> 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.)
> 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.
> 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" ?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |