From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLtQs-0002HN-20 for qemu-devel@nongnu.org; Fri, 07 Mar 2014 06:59:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLtQj-0003Ps-Rl for qemu-devel@nongnu.org; Fri, 07 Mar 2014 06:59:17 -0500 Received: from cantor2.suse.de ([195.135.220.15]:37557 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLtQj-0003Op-IK for qemu-devel@nongnu.org; Fri, 07 Mar 2014 06:59:09 -0500 Message-ID: <5319B48A.3050500@suse.de> Date: Fri, 07 Mar 2014 12:59:06 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1393941656-29068-1-git-send-email-pbonzini@redhat.com> <531704E2.3010406@suse.de> <53170AD6.3040809@redhat.com> In-Reply-To: <53170AD6.3040809@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 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: Paolo Bonzini , qemu-devel@nongnu.org Cc: ehabkost@redhat.com, hutao@cn.fujitsu.com, mtosatti@redhat.com, Anthony Liguori , imammedo@redhat.com, Chen Fan , a.motakis@virtualopensystems.com, gaowanlong@cn.fujitsu.com Am 05.03.2014 12:30, schrieb Paolo Bonzini: > 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. >=20 > I don't think it should, apart from conflicts. This series only change= s > things about memory. CPUs are handled the same before and after the > patches. >=20 >> I didn't review it in-depth yet, but minor technical issues apart, I >> think we need to keep NUMA and CPU separate, >=20 > I agree. Here you agreed ... >> 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] >=20 > I think this is better; in our world we can have multiple sockets in th= e > same NUMA node. But CPUState =3D=3D thread, so you can have just /thre= ad[0] > -> /machine/unassigned/device[0]. ... but you seem to have missed my point about separation. Here the socket object is a child<> of the NUMA node and would get realized together with it but separate from the link<>ed CPUState. > Alternatively, and to keep CPU + NUMA even *more* separate: >=20 > /machine > /node[0] > /cpu[0] -> /machine/unassigned/device[0] > ... > /socket[0] > /core[0] > /thread[0] -> /machine/unassigned/device[0] > /unassigned > /device[0] Now this is pretty much my proposal ;) except that you retained the criticized "node" as name and moved "socket[0]" out of /machine/unassigned (I had /machine/peripheral in mind for -device) and keep the CPUState out of the socket object. Anthony had requested hot-add to happen via "device_add Xeon4242", adding a full socket object with 6 cores at once. In that case CPUState needs to be an integral part of that socket-derived device for recursive realization. Objects that are just link<>ed to wouldn't get automatically realized. Since the only two other places for creating an X86CPU are PC code plus cpu-add I don't envision problems with adding it as child<> to its core. >> 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 ti= me >> to catch this with an error message at least, even if the remodeling >> depending on it happens post-2.0. >=20 >> 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. >=20 > I think we can. Children and links look exactly the same from the outs= ide. Well, we can't qom-get/qom-set a path string from/to a child<> property, can we? But paths can indeed be resolved either way. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg