From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: Paging/sharing in 4.2 (Was: Re: 4.2 TODO update) Date: Tue, 13 Mar 2012 14:36:09 +0100 Message-ID: <20120313133609.GA15096@aepfle.de> References: <1331554278.23971.63.camel@zakaz.uk.xensource.com> <1331554805.23971.70.camel@zakaz.uk.xensource.com> <20120312130403.GA6270@aepfle.de> <1331559700.23971.106.camel@zakaz.uk.xensource.com> <20120313105426.GA26167@aepfle.de> <1331638622.23971.233.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1331638622.23971.233.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Tim (Xen.org)" , Andres Lagar-Cavilla , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Tue, Mar 13, Ian Campbell wrote: > 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). Ok, makes sense. > 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@zakaz.uk.xensource.com>), > 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. Yes. > 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). Sounds good. > 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. Yes. > 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. I think that a default of "none" would change behaviour. So having "xl" as default which makes the guests behave like before will remove surprises during upgrade to 4.2. > 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@zakaz.uk.xensource.com>. Or maybe this > corresponds to using "xl-auto" and "xl-manual" as the policies? I'm not sure about the manual mode. If one calls mem-paging-set or mem-balloon-set to change the target value, why not do it right away? > Thoughts? Thanks for the writeup, Ian! > I suppose I ought to go back to > <1330078304.8557.157.camel@zakaz.uk.xensource.com> 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? Yes, an updated description/proposal is useful IMHO. Olaf >