Re: Proposed new "memory capacity claim" hypercall/feature

[Ian Campbell <ian.campbell@citrix.com>]

On Mon, 2012-11-05 at 14:54 +0000, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:ian.campbell@citrix.com]
> > Sent: Monday, November 05, 2012 3:30 AM
> > To: Dan Magenheimer
> > Cc: Tim (Xen.org); Keir (Xen.org); Jan Beulich; Olaf Hering; George Dunlap; Ian Jackson; George
> > Shuklin; DarioFaggioli; xen-devel@lists.xen.org; Konrad Wilk; Kurt Hackel; Mukesh Rathor; Zhigang Wang
> > Subject: Re: Proposed new "memory capacity claim" hypercall/feature
> > 
> > On Mon, 2012-11-05 at 00:23 +0000, Dan Magenheimer wrote:
> > > There is no "free up enough memory on that host". Tmem doesn't start
> > > ballooning out enough memory to start the VM... the guests are
> > > responsible for doing the ballooning and it is _already done_.  The
> > > machine either has sufficient free+freeable memory or it does not;
> > 
> > How does one go about deciding which host in a multi thousand host
> > deployment to try the claim hypercall on?
> 
> I don't get paid enough to solve that problem :-)
> 
> VM placement (both for new domains and migration due to
> load-balancing and power-management) is dependent on a
> number of factors currently involving CPU utilization,
> SAN utilization, and LAN utilization, I think using
> historical trends on streams of sampled statistics.  This
> is very non-deterministic as all of these factors may
> vary dramatically within a sampling interval.
> 
> Adding free+freeable memory to this just adds one more
> such statistic.  Actually two, as it is probably best to
> track free separately from freeable since a candidate
> host that has enough free memory should have preference
> over one with freeable memory.
> 
> Sorry if that's not very satisfying but anything beyond that
> meager description is outside of my area of expertise.

I guess I don't see how your proposed claim hypercall is useful if you
can't decide which machine you should call it on, whether it's 10s, 100s
or 1000s of hosts. Surely you aren't suggesting that the toolstack try
it on all (or even a subset) of them and see which sticks?

By ignoring this part of the problem I think you are ignoring one of the
most important bits of the story, without which it is very hard to make
a useful and informed determination about the validity of the use cases
you are describing for the new call.

Ian.