From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [RFC PATCH] Exporting Guest RAM information for
 NUMA binding
Date: Mon, 21 Nov 2011 20:03:16 +0200
Message-ID: <4ECA9264.5000102@redhat.com>
References: <20111029184502.GH11038@in.ibm.com>
	<7816C401-9BE5-48A9-8BA9-4CDAD1B39FC8@suse.de>
	<20111108173304.GA14486@sequoia.sous-sol.org>
	<20111121150054.GA3602@in.ibm.com> <1321889126.28118.5.camel@twins>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Andrea Arcangeli <aarcange@redhat.com>, kvm list <kvm@vger.kernel.org>,
	dipankar@in.ibm.com, qemu-devel Developers <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>,
	Chris Wright <chrisw@sous-sol.org>, bharata@linux.vnet.ibm.com,
	Vaidyanathan S <svaidy@in.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <1321889126.28118.5.camel@twins>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On 11/21/2011 05:25 PM, Peter Zijlstra wrote:
> On Mon, 2011-11-21 at 20:48 +0530, Bharata B Rao wrote:
>
> > I looked at Peter's recent work in this area.
> > (https://lkml.org/lkml/2011/11/17/204)
> > 
> > It introduces two interfaces:
> > 
> > 1. ms_tbind() to bind a thread to a memsched(*) group
> > 2. ms_mbind() to bind a memory region to memsched group
> > 
> > I assume the 2nd interface could be used by QEMU to create
> > memsched groups for each of guest NUMA node memory regions.
>
> No, you would need both, you'll need to group vcpu threads _and_ some
> vaddress space together.
>
> I understood QEMU currently uses a single big anonymous mmap() to
> allocate the guest memory, using this you could either use multiple or
> carve up the big alloc into virtual nodes by assigning different parts
> to different ms groups.
>
> Example: suppose you want to create a 2 node guest with 8 vcpus, create
> 2 ms groups, each with 4 vcpu threads and assign half the total guest
> mmap to either.
>

Does ms_mbind() require that its vmas in its area be completely
contained in the region, or does it split vmas on demand?  I suggest the
latter to avoid exposing implementation details.

-- 
error compiling committee.c: too many arguments to function