From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support] Date: Tue, 17 Nov 2009 07:21:51 +0000 Message-ID: References: <940bcfd20911162256u76fe97d4h647284570066d6a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <940bcfd20911162256u76fe97d4h647284570066d6a@mail.gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dulloor Cc: Andre Przywara , Dan Magenheimer , "xen-devel@lists.xensource.com" , George Dunlap , Ian Pratt , Papagiannis Anastasios List-Id: xen-devel@lists.xenproject.org I think this is good. However, the socket and node ids can be fairly arbitrary small numbers -- we need a way for the admin to find out the topology and 'addresses' of physical cpus via xm. Perhaps a new 'xm cpu-list' command to basically dump the pcpu_tuple information in ascending order of node, then socket, then core, then thread, with one row per cpu: node socket core thread xen-cpu-id More info could be added beyond these five pieces of information, as we later see fit. An alternative would be to rename the socket/node identifiers in pyxc_physinfo, or even in Xen itself, to achieve contiguity. However I thin= k a cpu-list command would still be useful, and it's easy to implement. -- Keir On 17/11/2009 06:56, "Dulloor" wrote: > Attached is a patch to construct pcpu tuples of the form > (node.socket.core.thread), and (currently)used by xm vcpu-pin utility. >=20 > -dulloor >=20 > On Fri, Nov 13, 2009 at 11:02 AM, Keir Fraser > wrote: >> On 13/11/2009 15:40, "Ian Pratt" wrote: >>=20 >>>> Even better would be to have pCPUs addressable and listable explicitly= as >>>> dotted tuples. That can be implemented entirely within the toolstack, = and >>>> could even allow wildcarding of tuple components to efficiently expres= s >>>> cpumasks. >>>=20 >>> Yes, I'd certainly like to see the toolstack support dotted tuple notat= ion. >>>=20 >>> However, I just don't trust the toolstack to get this right unless xen = has >>> already set it up nicely for it with a sensible enumeration and defined >>> sockets-per-node, cores-per-socket and threads-per-core parameters. Xen >>> should >>> provide a clean interface to the toolstack in this respect. >>=20 >> Xen provides a topology-interrogation hypercall which should suffice for >> tools to build up a {node,socket,core,thread}<->cpuid mapping table. >>=20 >> =A0-- Keir >>=20 >>=20 >>=20 >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel >>=20