[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |