| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memor
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home