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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 19/12/12 12:53, George Dunlap wrote:
> When a request comes in for a certain amount of memory, it will go and 
> set each VM's max_pages, and the max tmem pool size.  It can then 
> check whether there is enough free memory to complete the allocation 
> or not (since there's a race between checking how much memory a guest 
> is using and setting max_pages).  If that succeeds, it can return 
> "success".  If, while that VM is being built, another request comes 
> in, it can again go around and set the max sizes lower.  It has to 
> know how much of the memory is "reserved" for the first guest being 
> built, but if there's enough left after that, it can return "success" 
> and allow the second VM to start being built.
> After the VMs are built, the toolstack can remove the limits again if 
> it wants, again allowing the free flow of memory.
> Do you see any problems with this scheme?  All it requires is for the 
> toolstack to be able to temporarliy set limits on both guests 
> ballooning up and on tmem allocating more than a certain amount of 
> memory.  We already have mechanisms for the first, so if we had a 
> "max_pages" for tmem, then you'd have all the tools you need to 
> implement it.
I should also point out, this scheme has some distinct *advantages*: 
Namely, that if there isn't enough free memory, such a daemon can easily 
be modified to *make* free memory by cranking down balloon targets 
and/or tmem pool size.
 -George

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