From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH RFC v2 4/7] libxl/vNUMA: vNUMA libxl
 functionality.
Date: Wed, 25 Sep 2013 13:50:00 -0400
Message-ID: <20130925175000.GB7253@phenom.dumpdata.com>
References: <1379062216-13855-1-git-send-email-ufimtseva@gmail.com>
	<CAFLBxZb-Mu=onvWJW33aCojON4U5-3-oi_uuOCgM98SHVMsE6w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <CAFLBxZb-Mu=onvWJW33aCojON4U5-3-oi_uuOCgM98SHVMsE6w@mail.gmail.com>
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: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, Li Yechen <lccycc123@gmail.com>, Dario Faggioli <dario.faggioli@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Elena Ufimtseva <ufimtseva@gmail.com>, sw@linux.com
List-Id: xen-devel@lists.xenproject.org

On Tue, Sep 17, 2013 at 05:36:18PM +0100, George Dunlap wrote:
> On Fri, Sep 13, 2013 at 9:50 AM, Elena Ufimtseva <ufimtseva@gmail.com> wrote:
> > vNUMA libxl supporting functionality.
> > libxl supporting functionality for vNUMA includes:
> > * having vNUMA memory areas sizes, transforms it to
> > start and end pfns based on domain e820 map;
> > * contructs vnode_to_pnode map for vNUMA nodes memory
> > allocation and pass it to Xen; the mechanism considers
> > automatic NUMA placement in case of presence of hardware
> > NUMA; In best case scenario all vnodes will be allocated
> > within one pnode. If the domain spans different pnodes,
> > the vnodes will be one-by-one placed to pnodes. If such
> > allocation is impossible due to the memory constraints,
> > the allocation will use default mechanism; this is worst
> > case scenario.
> 
> Why would someone want to make a VM with two vnodes and then put them
> on the same pnode?  Apart from testing, of course, but our defaults
> should be for the common case of real users.

Resource allocation wihin the guest. You can bind each application
to use the "fake" NUMA memory and in that way parition the applications
to be within their memory pools.

You can do that right now with the fake NUMA option that Linux
kernel provides.