From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLuKc-000239-JD for qemu-devel@nongnu.org; Fri, 07 Mar 2014 07:57:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLuKW-0005eW-J1 for qemu-devel@nongnu.org; Fri, 07 Mar 2014 07:56:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:14168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLuKW-0005eL-BP for qemu-devel@nongnu.org; Fri, 07 Mar 2014 07:56:48 -0500 Date: Fri, 7 Mar 2014 13:56:27 +0100 From: Igor Mammedov Message-ID: <20140307135627.55d135ac@thinkpad> In-Reply-To: <5319B99D.7070200@redhat.com> References: <1393941656-29068-1-git-send-email-pbonzini@redhat.com> <531704E2.3010406@suse.de> <53170AD6.3040809@redhat.com> <5319B48A.3050500@suse.de> <5319B99D.7070200@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 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 Cc: ehabkost@redhat.com, hutao@cn.fujitsu.com, mtosatti@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , Chen Fan , a.motakis@virtualopensystems.com, Andreas =?ISO-8859-1?B?RuRyYmVy?= , gaowanlong@cn.fujitsu.com On Fri, 07 Mar 2014 13:20:45 +0100 Paolo Bonzini wrote: > Il 07/03/2014 12:59, Andreas F=E4rber ha scritto: > > Am 05.03.2014 12:30, schrieb Paolo Bonzini: > >> Il 05/03/2014 12:05, Andreas F=E4rber ha scritto: > >>> 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. > > > > 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] > >> > >> I think this is better; in our world we can have multiple sockets in t= he > >> same NUMA node. But CPUState =3D=3D thread, so you can have just /thr= ead[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. >=20 > Ah, I didn't think the socket object as anything but a container. For=20 > me, "keep NUMA and CPU separate" meant "keep NUMA and CPUState separate". >=20 > >> 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] > > > > 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. we possible can't do it in arch independent manner, but if we are talking about 'pc' machine and would ever model real CPU composition there (is there reasons to do it?), then composite CPU object could still stay in internal /machine/unassigned|/machine/peripheral trees in parallel with public /machine/node[x]/socket[y]/core[z]/link[j] topology interf= ace >=20 > Yes, if you want to do this then you're right and /socket[n] needs to be= =20 > a device. >=20 > However, I'd still like it to be mostly a container, and that is why I=20 > liked the idea of having /node[n] with "flat" links to the actual=20 > CPUStates (and also memdevs). Is there a point in having flat links to CPUState at /nodeX level, idea to create [*] /node[x]/socket[y]/core[z]/link[j] tree, was suggested as way: 1. to expose stable arch independent topology interface to user 2. use * as argument to -device / device_add/del cpu,path=3Dfoo to avoid exposing arch dependent APIC ID to the user. while keeping /machine/node/socket/core objects mostly as containers to exp= ress above things. >=20 > >> I think we can. Children and links look exactly the same from the out= side. > > > > Well, we can't qom-get/qom-set a path string from/to a child<> property, > > can we? >=20 > We can get it but not set it. But Stefan's series provides a way to=20 > make links read-only too, and these links should be read-only I think. CPUState links are readonly only until no hotplug supported. >=20 > Paolo --=20 Regards, Igor