Re: [PATCH] RFC: initial libxl support for xenpaging

[George Dunlap <george.dunlap@citrix.com>]

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