Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions

[Tim Deegan <tim@xxxxxxx>]

At 16:45 -0500 on 18 Jan (1358527542), Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 17, 2013 at 03:16:31PM +0000, Tim Deegan wrote:
> > At 14:08 -0500 on 11 Jan (1357913294), Konrad Rzeszutek Wilk wrote:
> > > But the solution to the hypercall failing are multiple - one is to 
> > > try to "squeeze" all the guests to make space
> > 
> > AFAICT if the toolstack can squeeze guests up to make room then the
> > reservation hypercall isn't necessary -- just use the squeezing
> > mechanism to make sure that running VMs don't use up the memory you want
> > for building new ones.
> 
> We might want to not do that until we have run out of options (this would
> be a toolstack option to select the right choice). The other option is
> to just launch the guest on another node.

Sure, I see that; but what I meant was: the reservation hypercall only
makes any kind of sense if the toolstack can't squeeze the existing guests. 

If it can squeeze VMs, as part of that it must have some mechanism to
stop them from immediately re-allocating all the memory as it frees it.
So in the case where enough memory is already free, you just use that
mechanism to protect it while you build the new VM.

Or (since I get the impression that losing this allocation race is a
rare event) you can take the optimistic route: after you've checked that
enough memory is free, just start building the VM.  If you run out of
memory part-way through, you can squeeze the other VMs back out so you can
finish the job.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel