Re: [Xen-devel] Pointed questions re Xen memory overcommit

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

>> From: Olaf Hering [mailto:olaf@xxxxxxxxx]
>> Subject: Re: [Xen-devel] Pointed questions re Xen memory overcommit
>>
>> On Mon, Feb 27, Dan Magenheimer wrote:
>>
>> > > From: Olaf Hering [mailto:olaf@xxxxxxxxx]
>> > > To me memory overcommit means swapping, which is what xenpaging
>> does:
>> > > turn the whole guest gfn range into some sort of virtual memory,
>> > > transparent to the guest.
>> > >
>> > > xenpaging is the red emergency knob to free some host memory without
>> > > caring about the actual memory constraints within the paged guests.
>> >
>> > Sure, but the whole point of increasing RAM in one or more guests
>> > is to increase performance, and if overcommitting *always* means
>> > swapping, why would anyone use it?
>>
>> The usage patterns depend on the goal. As I wrote, swapping frees host
>> memory so it can be used for something else, like starting yet another
>> guest on the host.
>
> OK, I suppose xenpaging by itself could be useful in a situation such as:
>
> 1) A failover occurs from machine A that has lots of RAM to machine B
>    that has much less RAM, and even horribly bad performance is better
>    than total service interruption.
> 2) All currently running VMs have been ballooned down "far enough"
>    and either have no swap device or insufficiently-sized swap devices,
>    Xen simply has no more free space, and horrible performance is
>    acceptable.
>
> The historical problem with "hypervisor-based-swapping" solutions such
> as xenpaging is that it is impossible to ensure that "horribly bad
> performance" doesn't start occurring under "normal" circumstances
> specifically because (as Tim indirectly concurs below), policies
> driven by heuristics and external inference (i.e. dom0 trying
> to guess how much memory every domU "needs") just don't work.
>
> As a result, VMware customers outside of some very specific domains
> (domains possibly overlapping with Snowflock?) will tell you
> that "memory overcommit sucks and so we turn it off".
>
> Which is why I raised the question "why are we doing this?"...
> If the answer is "Snowflock customers will benefit from it",

How come SnowFlock crept in here? :)

I can unequivocally assert there is no such thing as "SnowFlock customers".

You have to keep in mind that paging is 1. not bad to have and 2. powerful
and generic, and 3. a far more generic mechanism to populating on demand,
than what is labeled in the hypervisor as "populate-on-demand".

Re 2. you could implement a balloon using a pager -- or you could
implement a version of ramster by putting the page file on a fuse fs with
compression turned on. Not that you would want to, just to prove a point.

And re 3. not that there's anything wrong with PoD, but it has several
assumptions baked in about being a temporary balloon replacement. I
predict that once 32 bit hypervisor and shadow mode are phased out, PoD
will also go away, as it will be a "simple" sub-case of paging.

Olaf Hering from SuSe invested significant time and effort in getting
paging to where it is, so you also have to add to the list whatever
his/their motivations are.

Andres

> that's fine.  If the answer is "to handle disastrous failover
> situations", that's fine too.  And I suppose if the answer is
> "so that VMware can't claim to have a feature that Xen doesn't
> have (even if almost nobody uses it)", I suppose that's fine too.
>
> I'm mostly curious because I've spent the last four years
> trying to solve this problem in a more intelligent way
> and am wondering if the "old way" has improved, or is
> still just the old way but mostly warmed over for Xen.
> And, admittedly, a bit jealous because there's apparently
> so much effort going into the "old way" and not toward
> "a better way".
>
> Dan
>
>> <following pasted from earlier in thread>
>> From: Tim Deegan [mailto:tim@xxxxxxx]
>> Subject: Re: Pointed questions re Xen memory overcommit
>>
>> At 12:53 -0800 on 24 Feb (1330088020), Dan Magenheimer wrote:
>> > 3) Is there new evidence that a host-based-policy-driven memory
>> > balancer works sufficiently well on one system, or for
>> > multiple hosts, or for a data center?
>>
>> That, I think, is an open research question.
>



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