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/
Home Products Support Community News


Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memor

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 01 Sep 2010 14:17:39 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 01 Sep 2010 14:28:22 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43844cf2-4c99-448c-a98c-3100baae6dcc@default>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <alpine.DEB.2.00.1008271215210.2545@kaball-desktop> <19581.15132.637644.952724@xxxxxxxxxxxxxxxxxxxxxxxx 4C7E94F0.5050802@xxxxxxxx> <43844cf2-4c99-448c-a98c-3100baae6dcc@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 On 09/01/2010 01:03 PM, Dan Magenheimer wrote:
> Indeed, that's what selfballooning does.  The xenstore watch
> is irrelevant for selfballooning (though the watch also can be used
> asynchronously for backwards compatibility).

There's no mechanism to make the balloon driver ignore the target watch,
so any updates to xenstore will update the driver's target.

> IMHO, attempts to do memory load balancing externally (e.g. setting
> a memory target from tools in dom0) are doomed to failure.  There 
> was a discussion of memory "rightsizing" at the recent Linux MM summit;
> this is an almost impossible problem even within a single kernel,
> though there were heuristics discussed as to how to approach it...
> and a better understanding about why in-kernel tmem-ish functionalities
> like cleancache and frontswap are useful for mitigating the problems
> that occur when rightsizing is approximated.
> [...]
> So, frankly, I think the "xm memset" functionality is largely
> useless, but agree that it should be maintained in xl for backwards
> compatibility.  But trying to comingle the concepts of maxmem
> and target is a bad idea.

In the general case I think you're probably right (I can't see it being
useful in a VPS hosting service, for example), but there are definitely
special cases where it is useful.  Squashing down existing domains to
make room for a new one, for example, or more app-specific uses.

Giving domains some real incentive to be economical with memory would
probably change the landscape a lot.  But I don't think there's a real
solution without knowing the specifics of that incentive.


Xen-devel mailing list