Re: [Xen-devel] domain creation vs querying free memory (xend and xl)

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Andres Lagar-Cavilla [mailto:andreslc@xxxxxxxxxxxxxx]
> Subject: Re: [Xen-devel] domain creation vs querying free memory (xend and xl)
> 
> On Oct 4, 2012, at 6:06 AM, Tim Deegan wrote:
> 
> > At 14:56 -0700 on 02 Oct (1349189817), Dan Magenheimer wrote:
> >> Tmem argues that doing "memory capacity transfers" at a page granularity
> >> can only be done efficiently in the hypervisor.  This is true for
> >> page-sharing when it breaks a "share" also... it can't go ask the
> >> toolstack to approve allocation of a new page every time a write to a 
> >> shared
> >> page occurs.
> >>
> >> Does that make sense?
> >
> > Yes.  The page-sharing version can be handled by having a pool of
> > dedicated memory for breaking shares, and the toolstack asynchronously
> > replenish that, rather than allowing CoW to use up all memory in the
> > system.
> 
> That is doable. One benefit is that it would minimize the chance of a VM 
> hitting a CoW ENOMEM. I don't
> see how it would altogether avoid it.

Agreed, so it doesn't really solve the problem.  (See longer reply
to Tim.)
 
> If the objective is trying to put a cap to the unpredictable growth of memory 
> allocations via CoW
> unsharing, two observations: (1) will never grow past nominal VM footprint 
> (2) One can put a cap today
> by tweaking d->max_pages -- CoW will fail, faulting vcpu will sleep, and 
> things can be kicked back
> into action at a later point.

But IIRC isn't it (2) that has given VMware memory overcommit a bad name?
Any significant memory pressure due to overcommit leads to double-swapping,
which leads to horrible performance?

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