From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: Proposed new "memory capacity claim"
	hypercall/feature
Date: Mon, 29 Oct 2012 19:24:21 +0100
Message-ID: <CCB48865.42B90%keir.xen@gmail.com>
References: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <60d00f38-98a3-4ec2-acbd-b49dafaada56@default>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Dan Magenheimer <dan.magenheimer@oracle.com>, Jan Beulich <JBeulich@novell.com>
Cc: Olaf Hering <olaf@aepfle.de>, Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, George Dunlap <George.Dunlap@eu.citrix.com>, George Shuklin <george.shuklin@gmail.com>, "Tim (Xen.org)" <tim@xen.org>, xen-devel@lists.xen.org, Dario Faggioli <raistlin@linux.it>, Kurt Hackel <kurt.hackel@oracle.com>, Zhigang Wang <zhigang.x.wang@oracle.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 29/10/2012 18:06, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:

> The objective of the design is to ensure that a multi-threaded
> toolstack can atomically claim a specific amount of RAM capacity for a
> domain, especially in the presence of independent dynamic memory demand
> (such as tmem and selfballooning) which the toolstack is not able to track.
> "Claim X 50G" means that, on completion of the call, either (A) 50G of
> capacity has been claimed for use by domain X and the call returns
> success or (B) the call returns failure.  Note that in the above,
> "claim" explicitly does NOT mean that specific physical RAM pages have
> been assigned, only that the 50G of RAM capacity is not available either
> to a subsequent "claim" or for most[2] independent dynamic memory demands.

I don't really understand the problem it solves, to be honest. Why would you
not just allocate the RAM pages, rather than merely making that amount of
memory unallocatable for any other purpose?

 -- Keir