From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLtm6-000602-3z for qemu-devel@nongnu.org; Fri, 07 Mar 2014 07:21:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLtlw-0002hz-Lz for qemu-devel@nongnu.org; Fri, 07 Mar 2014 07:21:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:19931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLtlw-0002ht-EZ for qemu-devel@nongnu.org; Fri, 07 Mar 2014 07:21:04 -0500 Message-ID: <5319B99D.7070200@redhat.com> Date: Fri, 07 Mar 2014 13:20:45 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1393941656-29068-1-git-send-email-pbonzini@redhat.com> <531704E2.3010406@suse.de> <53170AD6.3040809@redhat.com> <5319B48A.3050500@suse.de> In-Reply-To: <5319B48A.3050500@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 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 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. 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". >> 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 recursiv= e > realization. Objects that are just link<>ed to wouldn't get > automatically realized. Yes, if you want to do this then you're right and /socket[n] needs to be=20 a device. 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). >> 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? 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. Paolo