RE: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Thanks for cc'ing me Jeremy... I saw the posting but missed
the implications (thinking it just a vanilla reimplementation of
"xm memset").

> There needs to be a way to set the maxmem for a domain without also
> setting the memory/target xenstore key, so that you can allow a domain
> to control its own ballooning up to a certain limit without also
> triggering its xenstore watch (which would trigger an external balloon
> target request).

Indeed, that's what selfballooning does.  The xenstore watch
is irrelevant for selfballooning (though the watch also can be used
asynchronously for backwards compatibility).

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.

> There's also the question of how tmem makes use of maxmem - I believe
> it
> allows a domain to use tmem pages up to its maxmem, without actually
> changing the current memory usage in terms of pages mapped into the
> domain.

There are two classes of tmem memory: ephemeral and persistent.
Ephemeral is clean pages that can be discarded at any time and
tmem doesn't count those against maxmem.  Persistent pages
must be retained until the guest that "owns" them flushes
them or dies; these pages DO count against the guest's maxmem
but are not mapped into the domain.

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.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel