WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] linux/balloon:don't allow ballooningdowna domain

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] linux/balloon:don't allow ballooningdowna domain below a reasonable limit
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 2 May 2008 16:22:45 -0600
Cc: Ky Srinivasan <KSrinivasan@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx>, "garloff@xxxxxxx" <garloff@xxxxxxx>
Delivery-date: Fri, 02 May 2008 15:23:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <481B7A01020000780004B919@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcisowjyV3DkpIWjQsChPI7vSncdJg==
> >OK, I think I am understanding it a bit better:
> >the max_pfn part is just adding in some "slop"
> >which is a fraction of total main memory which
> >is growing smaller (roughly logarithmically)
> >as memory grows larger.  I'm still not sure about
> >the magic values in MB2PAGES though... I'm guessing
> >these were gathered somehow experimentally?
> 
> I have to defer to the original author here - Kurt?

Eagerly awaiting... In addition to cutting it
in half, I subtracted another 10MB (in a memory=512
domain) and still didn't see any OOMs, though my
testing was admittedly limited.
 
> >With the "divide result of your algorithm by two",
> >I was able to get thirteen 512MB domains (idle
> >for now) running on a 2GB system.
> 
> You mean ballooned-down domains, right? Perhaps using your
> self-ballooning change? I have to admit I'm a little nervous
> about attempting to overcommit memory in this way in a
> production environment, but as long as this depends on a
> decision of the operator it's certainly a good option to have.

Yes, ballooned-down domains.  In fact with minimum_target()
modified as above (half of algorithm minus 10MB) and
a variable load (repeating { compile xen; sleep(30<rand<541) }),
I got fifteen 512MB domains running on a 2GB systems.

Agreed that there are many environments where this kind
of ballooning would cause performance problems (or worse).
However, there are certainly some environments (and some
competitive situations ;-) where one might choose to
tradeoff performance to run more VMs per physical machine.

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel