From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <dunlapg@umich.edu>
Subject: Re: [PATCH 2/4] libxc: report how much memory a domain
 has on each NUMA node
Date: Thu, 13 Mar 2014 11:54:46 +0000
Message-ID: <CAFLBxZbZSTeUUJhv1pfJ6Sp3RgW7_h5yU1s3hgG7Kp67OdG8Bw@mail.gmail.com>
References: <20140305143357.6984.7729.stgit@Solace>
	<20140305143635.6984.34422.stgit@Solace>
	<21277.60093.406016.679465@mariner.uk.xensource.com>
	<1394471250.17832.11.camel@Solace>
	<21277.62587.257049.744094@mariner.uk.xensource.com>
	<1394472929.17832.31.camel@Solace>
	<21278.61493.651392.622482@mariner.uk.xensource.com>
	<1394559445.17832.61.camel@Solace>
	<21279.21271.697986.707363@mariner.uk.xensource.com>
	<1394564642.17832.78.camel@Solace>
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: <1394564642.17832.78.camel@Solace>
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: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Juergen Gross <juergen.gross@ts.fujitsu.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, Daniel De Graaf <dgdegra@tycho.nsa.gov>
List-Id: xen-devel@lists.xenproject.org

On Tue, Mar 11, 2014 at 7:04 PM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On mar, 2014-03-11 at 18:16 +0000, Ian Jackson wrote:
>> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 2/4] libxc: report how much memory a domain has on each NUMA node"):
>> > In the current NUMA placement implementation, in libxl, what we need to
>> > know is how much memory is free on each node, rather than how much
>> > memory each domain occupies there.
>> >
>> > So, what is it that I should try to show you?
>>
>> I want a sketch of a race-free memory assignment approach that works
>> with ballooning (and domain self-directed numa migration), and doesn't
>> depend on arbitrating memory usage by having Xen fail certain memory
>> allocations.
>>
> Mmm... I think I see what you mean now (except perhaps for the "domain
> self-directed numa migration" part).
>
> I also still don't think that this specific call/functionality should be
> subject to (that much) locking, at least not at this level, but I see
> the value of having a plan.

I think it's worth taking a little bit of time seeing if we can make
an interface that could be used by a toolstack for such a purpose.
But if it's overly complicated, I don't see a problem with having one
interface just for information, and come up with a new race-free
interface once someone shows up that actually needs it.  Otherwise we
risk spending a lot of time inventing an API that turns out not to be
suitable for purpose anyway.

 -George