Re: [Xen-devel] [PATCH] RFC: initial libxl support for xenpaging

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

> On Thu, 2012-02-23 at 10:42 +0000, Ian Campbell wrote:
>> What if you switch back without making sure you are in such a state? I
>> think switching between the two is where the potential for unexpected
>> behaviour is most likely.
>
> Yeah, correctly predicting what would happen requires understanding what
> mem-set does under the hood.
>
>> I like that you have to explicitly ask for the safety wheels to come off
>> and explicitly put them back on again. It avoids the corner cases I
>> alluded to above (at least I hope so).
>
> Yes, I think your suggestion sounds more like driving a car with a
> proper hood, and less like driving a go-kart with the engine
> exposed. :-)
>
>> Without wishing to put words in Andres' mouth I expect that he intended
>> "footprint" to cover other technical means than paging too --
>> specifically I expect he was thinking of page sharing. (I suppose it
>> also covers PoD to some extent too, although that is something of a
>> special case)
>>
>> While I don't expect there will be a knob to control number of shared
>> pages (either you can share some pages or not, the settings would be
>> more about how aggressively you search for sharable pages) it might be
>> useful to consider the interaction between paging and sharing, I expect
>> that most sharing configurations would want to have paging on at the
>> same time (for safety). It seems valid to me to want to say "make the
>> guest use this amount of actual RAM" and to achieve that by sharing what
>> you can and then paging the rest.
>
> Yes, it's worth thinking about; as long as it doesn't stall the paging
> UI too long. :-)
>
> The thing is, you can't actually control how much sharing happens.  That
> depends largely on whether the guests create and maintain pages which
> are share-able, and whether the sharing detection algorithm can find
> such pages.  Even if two guests are sharing 95% of their pages, at any
> point one of the guests may simply go wild and change them all.  So it
> seems to me that shared pages need to be treated like sunny days in the
> UK: Enjoy them while they're there, but don't count on them. :-)
>
> Given that, I think that each VM should have a "guaranteed minimum
> memory footprint", which would be the amount of actual host ram it will
> have if suddenly no shared pages become available.  After that, there
> should be a policy of how to use the "windfall" or "bonus" pages
> generated by sharing.
>
> One sensible default policy would be "givers gain": Every guest which
> creates a page which happens to be shared by another VM gets a share of
> the pages freed up by the sharing.  Another policy might be "communism",
> where the freed up pages are shared among all VMs, regardless of whose
> pages made the benefit possible.  (In fact, if shared pages come from
> zero pages, they should probably be given to VMs with no zero pages,
> regardless of the policy.)
>
> However, I'd say the main public "knobs" should be just consist of two
> things:
> * xl mem-set memory-target.  This is the minimum amount of physical RAM
> a guest can get; we make sure that the sum of these for all VMs does not
> exceed the host capacity.
> * xl sharing-policy [policy].  This tells the sharing system how to use
> the "windfall" pages gathered from page sharing.
>
> Then internally, the sharing system should combine the "minimum
> footprint" with the number of extra pages and the policy to set the
> amount of memory actually used (via balloon driver or paging).
>
> You could imagine a manual mode, where the administrator shares out the
> extra pages manually to VMs that he thinks needs them; but because those
> extra pages may go away at any time, that needs to be a separate knob
> (and preferably one which most admins don't ever touch).
>
> Andres, what do you think?

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 :)

My two cents
Andres

>
>  -George
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel