From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 3/4] sysctl: Add sysctl interface for querying PCI topology Date: Wed, 7 Jan 2015 18:55:40 +0100 Message-ID: <1420653340.17031.93.camel@Abyss.station> References: <1420510737-22813-1-git-send-email-boris.ostrovsky@oracle.com> <1420510737-22813-4-git-send-email-boris.ostrovsky@oracle.com> <54AD08AE02000078000522B7@mail.emea.novell.com> <54AD48D1.5000904@oracle.com> <54AD5C2D02000078000525F0@mail.emea.novell.com> <54AD569B.7070307@oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6109656731782186903==" Return-path: In-Reply-To: <54AD569B.7070307@oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, Jan Beulich , keir@xen.org, ufimtseva@gmail.com List-Id: xen-devel@lists.xenproject.org --===============6109656731782186903== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-EUD6iqn7nYqK2UO2bv6r" --=-EUD6iqn7nYqK2UO2bv6r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-01-07 at 10:54 -0500, Boris Ostrovsky wrote: > On 01/07/2015 10:17 AM, Jan Beulich wrote: > >> This is the same information (pxm -> node mapping ) that we provide in > >> XEN_SYSCTL_topologyinfo (renamed in this series to > >> XEN_SYSCTL_cputopoinfo). Given that I expect the two topologies to be > >> used together I think the answer is yes. > > Building your argumentation on potentially mis-designed existing > > interfaces is bogus. The question is - what use is a Xen internal > > node number to a caller of a particular hypercall (other than it > > being purely informational, e.g. for printing human readable > > output)? >=20 > Just as with knowing CPU/memory topology --- this will help with placing= =20 > a guest if we know what "proximity domain" both the device and the=20 > CPUs/memory belong to. >=20 FWIW, my view on how IONUMA information could be useful is this: either somewhere inside toolstack, automatically, or by hand, one may want to reason as follows: "Ehi, network card X is on node #2, let's place domain d, to which I'm passing through such card, on node #2 (or as much and as close as possible to node #2), to get best performance!" Of course, when inside the toolstack, we can do this automatically: "Domain d does not come with any affinity/placement information, but it is passed through net card X, which is on node #2, so let's try to place it on node #2 too" So, I think I agree with Boris that at least consistency is necessary. Right now, pretty much everything at both the toolstack (libxl) and command line (xl, for doing things by hand) level, uses node IDs reported by the hypervisor, as this series is also doing. In particular, at the command line level, affinity, cpupools, vNUMA (as per Wei's patches)... Everything speaks "node ID language", AFAICT. There probably would not be too serious issues in converting everything to PXM, or adding duplicates, but I don't see the reason why we should do such a thing... Perhaps I'm missing what using PXM would actually buy us? > And if we are going to keep this as a sysctl then we need to be=20 > consistent with what we do now for CPUs, which is pxm2node[]. Or change= =20 > CPU topology sysctl as well,=20 > Indeed, and not only that. > which I don't think is a good idea. >=20 Me neither. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-EUD6iqn7nYqK2UO2bv6r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlStcxwACgkQk4XaBE3IOsTHBACffcegjOZ29iBCsW/m8oK2vXaZ vWwAnjpvY3EJk5bqILZ7/RU4wRO6gOZ5 =tXM6 -----END PGP SIGNATURE----- --=-EUD6iqn7nYqK2UO2bv6r-- --===============6109656731782186903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6109656731782186903==--