[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Mon, 19 Mar 2012 09:17:36 -0700
  • Cc: George Dunlap <george.dunlap@xxxxxxxxxxxxx>, Olaf Hering <olaf@xxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 19 Mar 2012 16:17:55 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=m6SxdcQXYD0ieZPehhfxsSsB+a6tfI1CxKHqRyTKywxp KibF0fiOKBm0OHKEwR/mEn6U7sWVL3tnv/Djhi3DBLg62omhUd1uwylthtMuST/C aceufMONvFPyBPQj6WcK/8eMROowPVFtzYATG4iSNrAdMFfGN3H/witwLDJf2/M=
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

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

I hope once an actor is set it cannot be undone for the lifetime of the
domain.

If that sounds too rigid, then once an actor is torn down, it is
responsible for bringing things back to where they were. xenpaging does
this. And the xl default policy can easily reset the balloon to the
original target (i.e. no ballooned pages).

The memory-policy/target parameter should also be reset when an actor is
torn down.

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

Depends on whether xenpaging had been invoked previously. But I agree on
not immediately enforcing any values. If it's manual, then let the user
manually set all the knobs.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.