Re: [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target

[Jeremy Fitzhardinge <jeremy@goop.org>]

 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.

    J