From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41605) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMoKd-0004e5-RK for qemu-devel@nongnu.org; Mon, 11 Jul 2016 23:26:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMoKZ-0002sK-Jo for qemu-devel@nongnu.org; Mon, 11 Jul 2016 23:25:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMoKZ-0002sG-C6 for qemu-devel@nongnu.org; Mon, 11 Jul 2016 23:25:55 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ADA5546203 for ; Tue, 12 Jul 2016 03:25:54 +0000 (UTC) Date: Tue, 12 Jul 2016 13:27:41 +1000 From: David Gibson Message-ID: <20160712132741.59840413@voom.fritz.box> In-Reply-To: <20160708074600.GB78006@andariel.pipo.sk> References: <417b83d0e074e2004aa35bef337d32ac2c89f559.1467904342.git.pkrempa@redhat.com> <20160708122308.1f43b56a@voom.fritz.box> <20160708074600.GB78006@andariel.pipo.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/eWxzYZu6Ngcuo2R_z3Oiabo"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [RFC PATCH 2/2] numa: Add node_id data in query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Krempa Cc: qemu-devel@nongnu.org, imammedo@redhat.com --Sig_/eWxzYZu6Ngcuo2R_z3Oiabo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 8 Jul 2016 09:46:00 +0200 Peter Krempa wrote: > On Fri, Jul 08, 2016 at 12:23:08 +1000, David Gibson wrote: > > On Thu, 7 Jul 2016 17:17:14 +0200 > > Peter Krempa wrote: > > =20 > > > Add a helper that looks up the NUMA node for a given CPU and use it to > > > fill the node_id in the PPC and X86 impls of query-hotpluggable-cpus.= =20 > >=20 > >=20 > > IIUC how the query thing works this means that the node id issued by > > query-hotpluggable-cpus will be echoed back to device add by libvirt. = =20 >=20 > It will be echoed back, but the problem is that it's configured > separately ... >=20 > > I'm not sure we actually process that information in the core at > > present, so I don't know that that's right. > >=20 > > We need to be clear on which direction information is flowing here. > > Does query-hotpluggable-cpus *define* the NUMA node allocation which is > > then passed to the core device which implements it. Or is the NUMA > > allocation defined elsewhere, and query-hotpluggable-cpus just reports > > it. =20 >=20 > Currently (in the pre-hotplug era) the NUMA topology is defined by > specifying a CPU numbers (see previous patch) on the commandline: >=20 > -numa node=3D1,cpus=3D1-5,cpus=3D8,cpus=3D11... >=20 > This is then reported to the guest. >=20 > For a machine started with: >=20 > -smp 5,maxcpus=3D8,sockets=3D2,cores=3D2,threads=3D2 > -numa node,nodeid=3D0,cpus=3D0,cpus=3D2,cpus=3D4,cpus=3D6,mem=3D500 > -numa node,nodeid=3D1,cpus=3D1,cpus=3D3,cpus=3D5,cpus=3D7,mem=3D500 >=20 > you get the following topology that is not really possible with > hardware: >=20 > # lscpu > Architecture: x86_64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Little Endian > CPU(s): 5 > On-line CPU(s) list: 0-4 > Thread(s) per core: 1 > Core(s) per socket: 2 > Socket(s): 2 > NUMA node(s): 2 > Vendor ID: GenuineIntel > CPU family: 6 > Model: 6 > Model name: QEMU Virtual CPU version 2.5+ > Stepping: 3 > CPU MHz: 3504.318 > BogoMIPS: 7008.63 > Hypervisor vendor: KVM > Virtualization type: full > L1d cache: 32K > L1i cache: 32K > L2 cache: 4096K > NUMA node0 CPU(s): 0,2,4 > NUMA node1 CPU(s): 1,3 >=20 > Note that the count of cpus per numa node does not need to be identical. >=20 > As of the above 'query-hotpluggable-cpus' will need to report the data > that was configured above even if it doesn't make much sense in a real > world. >=20 > I did not try the above on a PPC host and thus I'm not sure whether the > config above is allowed or not. It's not - although I'm not sure that we actually have something enforcing this. However, single cores *must* be in the same NUMA node - there's no way of reporting to the guest anything finer grained. > While for the hotplug cpus it would be possible to plug in the correct > one according to the requested use the queried data but with the current > approach it's impossible to set the initial vcpus differently. >=20 > Peter >=20 > Note: For libvirt it's a no-go to start a throwaway qemu process just to > query the information and thus it's desired to have a way to configure > all this without the need to query with a specific machine > type/topology. --=20 David Gibson Senior Software Engineer, Virtualization, Red Hat --Sig_/eWxzYZu6Ngcuo2R_z3Oiabo Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXhGOtAAoJEGw4ysog2bOSm6IQALfBenJEreuOhUZT4RRFVHv8 UE/NP2rLwKfWhG5J1fam9SXONGIURTw5xDczMga7ly1DfV18g5xnSIJ1vFnX8AkH AuX6SFK7HGzC4f447jxMLnD001+Pr837RvhzvTdHdmUie3Cvug7Pu9uzgvGc7X+F j5NJUQwvo/wW0+Wgq+kWMrPI5l597RHBR9pZbEMSErG7ojtJuuh1XIGd3PIzQRvk 7ZtYYMhvdnyYQVpBeDKbeHVg9qzDByiJqHJ+GHohMc/WXf0H/VOTR3c2QmO6bH4k h8marQdBE75DPAvRFV6hU2wH/lmz3v9uQRRO8TCl0U18tYdT21tRfUA4meFgeUkR I0Y6ICV+kFQIVyPe7Yg/SBUXahQLrxfXcK0tShy3sHvmJTolCwkpVHzO7CfX6Jfw IyAoCAZAAvJymPXsCBFCzLpuxsZpOmPgCUHOOmAray8mCyO0CnTLLiyf1gFqVLqG Ifgp04xRm9rpxuTKLn+JAfJGeoLRZ9tZCi6pfCvqlrKU17T3TpnYqQJECHOcnlGI N0cxVH4qBmQk+7Blpth1xDu9cLLPuoNAyI1NLjtQFyr5GaPUx2maKRKM5RcxVCjJ nXQeP0kbVJ5iFnclqfs1IG9fQlaopgSDTdSBhq/JHPP6laQyTzQnb3xZGOlgl5uv Znp5WvoIAkFZUFBEVztm =WXb3 -----END PGP SIGNATURE----- --Sig_/eWxzYZu6Ngcuo2R_z3Oiabo--