From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqm45-00063C-Ib for qemu-devel@nongnu.org; Wed, 11 Dec 2013 10:51:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vqm3x-0008DP-66 for qemu-devel@nongnu.org; Wed, 11 Dec 2013 10:51:09 -0500 Received: from mail-qc0-x234.google.com ([2607:f8b0:400d:c01::234]:41453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqm3x-0008DG-1B for qemu-devel@nongnu.org; Wed, 11 Dec 2013 10:51:01 -0500 Received: by mail-qc0-f180.google.com with SMTP id w7so5241197qcr.11 for ; Wed, 11 Dec 2013 07:51:00 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52A889C8.3050902@redhat.com> Date: Wed, 11 Dec 2013 16:50:32 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1386764361-15260-1-git-send-email-pbonzini@redhat.com> <1386764361-15260-15-git-send-email-pbonzini@redhat.com> <20131211163626.3540983d@thinkpad> In-Reply-To: <20131211163626.3540983d@thinkpad> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 14/14] numa: add -numa node, memdev= option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: stefanha@redhat.com, qemu-devel@nongnu.org, gaowanlong@cn.fujitsu.com Il 11/12/2013 16:36, Igor Mammedov ha scritto: >> > -object memory-ram,size=1024M,policy=membind,host-nodes=0,id=ram-node0 \ >> > -numa node,nodeid=0,cpus=0,memdev=ram-node0 \ >> > -object memory-ram,size=1024M,policy=interleave,host-nodes=1-3,id=ram-node1 \ >> > -numa node,nodeid=1,cpus=1,memdev=ram-node1 > > I was thinking about a bit more radical change: > -object memory-ram,size=1024M,policy=membind,host-nodes=0,id=ram-node0 > -device dimm,memdev=ram-node0,node=0 > -object memory-ram,size=1024M,policy=membind,host-nodes=1,id=ram-node1 > -device dimm,memdev=ram-node1,node=1 > > that would allow to avoid synthetic -numa option You still need -numa for cpus, at least in the short/medium-term. > but would require conversion > of initial RAM to dimms. That would be more flexible for example allowing > bind several backends to one node (like: 1Gb_hugepage + 2Mb_hugepage ones) Yes, that's another possibility, perhaps even cleaner. With "-numa node,memdev=", your board only needs to use memory_region_allocate_system_memory in order to apply a NUMA policy to guest RAM; it also works with guests or boards that are not themselves NUMA-aware. Doing the same with "-device dimm" requires changing the board to support RAM-as-dimms; do you have any idea how easy/hard that would be? Paolo