From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLA2F-0000VA-Oc for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:30:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLA29-0003Fr-QZ for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:30:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLA29-0003Fl-EJ for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:30:45 -0500 Message-ID: <53170AD6.3040809@redhat.com> Date: Wed, 05 Mar 2014 12:30:30 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1393941656-29068-1-git-send-email-pbonzini@redhat.com> <531704E2.3010406@suse.de> In-Reply-To: <531704E2.3010406@suse.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2.1 00/28] Current state of NUMA series, and hostmem improvements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org, Chen Fan Cc: ehabkost@redhat.com, hutao@cn.fujitsu.com, mtosatti@redhat.com, imammedo@redhat.com, a.motakis@virtualopensystems.com, gaowanlong@cn.fujitsu.com Il 05/03/2014 12:05, Andreas F=E4rber ha scritto: > Am 04.03.2014 15:00, schrieb Paolo Bonzini: >> This series includes all the pending work on QOMifying the memory >> backends. > [snip] > > There's also a recent RFC from Chen Fan about how to model the > association between NUMA nodes and CPU socket/core/thread that > would/should influence this series if we're aiming for 2.1 now. I don't think it should, apart from conflicts. This series only changes=20 things about memory. CPUs are handled the same before and after the=20 patches. > I didn't review it in-depth yet, but minor technical issues apart, I > think we need to keep NUMA and CPU separate, I agree. > Compare that to: > > /machine > /node[0] # This is not really telling! > /socket[0] > /core[0] > /thread[0] # So CPUState !=3D thread? > cpu -> /machine/unassigned/device[0] > /unassigned > /device[0] I think this is better; in our world we can have multiple sockets in the=20 same NUMA node. But CPUState =3D=3D thread, so you can have just /thread= [0]=20 -> /machine/unassigned/device[0]. Alternatively, and to keep CPU + NUMA even *more* separate: /machine /node[0] /cpu[0] -> /machine/unassigned/device[0] ... /socket[0] /core[0] /thread[0] -> /machine/unassigned/device[0] /unassigned /device[0] > which then brings up the > question Chen Fan asked about whether we need to support splitting CPU > threads of one core or CPU cores of one socket onto different NUMA > nodes. If we can stop supporting this, 2.0 would be a good point in tim= e > to catch this with an error message at least, even if the remodeling > depending on it happens post-2.0. > Note that according to my interpretation of QOM ABI stability rules we > can't just turn a link into a child without renaming, thus > trying to be forward-looking for where we want to go design-wise. I think we can. Children and links look exactly the same from the outsid= e. Paolo