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

> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
>  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.

The selfballooning patch currently applies to the balloon driver
so it could easily disable the target watch, though it does not.
> > 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.

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.
> 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.


Xen-devel mailing list