From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target Date: Wed, 1 Sep 2010 14:49:22 -0700 (PDT) Message-ID: <7352ab89-2dd6-4d15-99cd-04867849f399@default> References: <19581.15132.637644.952724@mariner.uk.xensource.com> <4C7E94F0.5050802@goop.org> <43844cf2-4c99-448c-a98c-3100baae6dcc@default 4C7EC2F3.3050704@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4C7EC2F3.3050704@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: xen-devel@lists.xensource.com, Ian Jackson , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] >=20 > 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). >=20 > There's no mechanism to make the balloon driver ignore the target > watch, > so any updates to xenstore will update the driver's target. The selfballooning patch currently applies to the balloon driver so it could easily disable the target watch, though it does not. =20 > > 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. >=20 > 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. Agreed in general, though I suspect sysadmins would be rather peeved if/when a simple xm command in dom0 causes kernel OOMs and application kills... or, worse, guest kernel crashes (which are circumvented by minimum-target code in the linux-xen balloon driver but NOT in the pvops balloon driver). So "useless" is an overstatement, but "must be used extremely carefully with knowledge of current activity in the guest and/or willingness for the targeted guest or its applications to die for a greater cause" is not an overstatement. =20 > 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. Agreed. Lacking a clear incentive though, reducing the disincentive is a reasonable approach... which is what tmem+selfballooning does. My long term view of the incentive is something like a VPS hoster that offers service for $10/month, but offers it for $5/month if using a tmem(+selfballooning)-enabled kernel. This is essentially like the electric utility companies that give customers a discount if the customer allows them a remote-kill switch to turn off your air conditioning if system-wide conditions warrant. Dan