From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLwAZ-0005mW-KZ for qemu-devel@nongnu.org; Fri, 07 Mar 2014 09:54:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WLwAT-0005Nf-HN for qemu-devel@nongnu.org; Fri, 07 Mar 2014 09:54:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WLwAT-0005NR-7x for qemu-devel@nongnu.org; Fri, 07 Mar 2014 09:54:33 -0500 Date: Fri, 7 Mar 2014 15:54:08 +0100 From: Igor Mammedov Message-ID: <20140307155408.3b626c31@thinkpad> In-Reply-To: <5319CB0D.30307@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> <20140307135627.55d135ac@thinkpad> <5319CB0D.30307@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 14:35:09 +0100 Paolo Bonzini wrote: > Il 07/03/2014 13:56, Igor Mammedov ha scritto: > >> However, I'd still like it to be mostly a container, and that is why I > >> liked the idea of having /node[n] with "flat" links to the actual > >> CPUStates (and also memdevs). > > > > Is there a point in having flat links to CPUState at /nodeX level, > > Easily getting thread ids for the VCPU thread and pinning them to host > nodes? For this you need to match the CPU numbers passed to "-numa > node", not some socket topology that can be completely arbitrary. CPU numbers, on -numa node, are coming from cpu_index legacy, and shouldn't we try to get rid of it in favor of something manageable? Since CPUs are now devices we could use "id" to specify CPUs on -numa node as one solution or use path names as with memdev. > > Paolo > > > 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=foo to avoid > > exposing arch dependent APIC ID to the user. > > while keeping /machine/node/socket/core objects mostly as containers to express > > above things. > > > >> > >>>> I think we can. Children and links look exactly the same from the outside. > >>> > >>> 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 > >> make links read-only too, and these links should be read-only I think. > > CPUState links are readonly only until no hotplug supported. > > > >> > >> Paolo > > > > > -- Regards, Igor