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