From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSZBX-0001FP-4r for qemu-devel@nongnu.org; Mon, 21 Nov 2011 14:05:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSZBS-00065F-Ec for qemu-devel@nongnu.org; Mon, 21 Nov 2011 14:05:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:5056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSZBS-000656-1i for qemu-devel@nongnu.org; Mon, 21 Nov 2011 14:05:38 -0500 Message-ID: <4ECA9264.5000102@redhat.com> Date: Mon, 21 Nov 2011 20:03:16 +0200 From: Avi Kivity MIME-Version: 1.0 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> In-Reply-To: <1321889126.28118.5.camel@twins> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Zijlstra Cc: Andrea Arcangeli , kvm list , dipankar@in.ibm.com, qemu-devel Developers , Alexander Graf , Chris Wright , bharata@linux.vnet.ibm.com, Vaidyanathan S 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