From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH] RFC: initial libxl support for xenpaging Date: Thu, 23 Feb 2012 17:30:02 +0000 Message-ID: <1330018202.19361.82.camel@elijah> References: <1329486241.3131.81.camel@zakaz.uk.xensource.com> <20120217142505.GA10523@aepfle.de> <1329490712.3131.97.camel@zakaz.uk.xensource.com> <20120217152443.GA16995@aepfle.de> <1329492796.3131.104.camel@zakaz.uk.xensource.com> <20120217154346.GA19731@aepfle.de> <1329494069.3131.109.camel@zakaz.uk.xensource.com> <20120217160341.GA22266@aepfle.de> <1329496998.3131.131.camel@zakaz.uk.xensource.com> <20120220111230.GA5856@aepfle.de> <1329818358.25232.64.camel@dagon.hellion.org.uk> <1329826841.2196.85.camel@elijah> <1329993761.8557.66.camel@zakaz.uk.xensource.com> <1329999531.19361.74.camel@elijah> <4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4bcfa50079afd429eeabd08721c6f0c3.squirrel@webmail.lagarcavilla.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "andres@lagarcavilla.org" Cc: George Dunlap , Olaf Hering , "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Thu, 2012-02-23 at 16:22 +0000, Andres Lagar-Cavilla wrote: > I think it's a lot to process :) I will issue a few statements in no > particular order. > > How about we have a BoF/powwow on this at the Hackathon? > > For the sake of expediency we need a simple UI, with two/three obvious > commands doing things, and then a full arsenal of knob-ery as a separate > entity. I agree with the general sentiment here. > > I actually intended footprint to convey a human-understandable name for > what paging is doing. I think if we try to combine under 'footprint' all > possible means of trimming pages from the guest, *in libxl*, we'll end up > pleasing nobody. > > Taking a few steps back, Olaf's purpose is to be able to control the *one* > knob xenpaging has with its linear sweep policy via libxl. (I guess you > have a second knob, throttling how fast you try to page in things back) > > Somebody has to ask this: are you really sure you want to bake policies > into libxl? What will toolstacks be left with? I think it's great to wire > some straightforward control of xenpaging into libxl -- as straightforward > control of the balloon and PoD is already in place. But when the > conversation starts escalating, the complexity of libxl grows > exponentially, and I get all kinds of shivers. > > The original stated goal of libxl is to be a common substrate for > toolstacks. Let toolstacks decide if they want fancier paging or Marxist > sharing, or what not :) Just a quick comment for clarification: We're talking now about xl, not libxl. Libxl, as you say, will expose all the knobs to the toolstack, and allow the toolstack to do what it wishes. But a large number of our customers will be using xl, which is, in fact, a toolstack built on libxl. :-) It's the interface to that toolstack we're discussing. I'll answer more in a bit. -George