From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwioI-0003yK-So for qemu-devel@nongnu.org; Wed, 19 Oct 2016 00:49:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwioA-0001Sa-8t for qemu-devel@nongnu.org; Wed, 19 Oct 2016 00:49:02 -0400 Date: Wed, 19 Oct 2016 13:09:40 +1100 From: David Gibson Message-ID: <20161019020940.GA11140@umbus.fritz.box> References: <1476823823-20365-1-git-send-email-mdroth@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <1476823823-20365-1-git-send-email-mdroth@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH] spapr_pci: advertise explicit numa IDs even when there's 1 node List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Roth Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Alexey Kardashevskiy , "Shivaprasad G. Bhat" --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2016 at 03:50:23PM -0500, Michael Roth wrote: > With the addition of "numa_node" properties for PHBs we began > advertising NUMA affinity in cases where nb_numa_nodes > 1. >=20 > Since the default on the guest side is to make no assumptions about > PHB NUMA affinity (defaulting to -1), there is still a valid use-case > for explicitly defining a PHB's NUMA affinity even when there's just > one node. In particular, some workloads make faulty assumptions about > /sys/bus/pci//numa_node being >=3D 0, warranting the use of > this property as a workaround even if there's just 1 PHB or NUMA > node. >=20 > Enable this use-case by always advertising the PHB's NUMA affinity > if "numa_node" has been explicitly set. >=20 > We could achieve this by relaxing the check to simply be > nb_numa_nodes > 0, but even safer would be to check > numa_info[nodeid].present explicitly, and to fail at start time > for cases where it does not exist. >=20 > This has an additional affect of no longer advertising PHB NUMA > affinity unconditionally if nb_numa_nodes > 1 and "numa_node" > property is unset/-1, but since the default value on the guest > side for each PHB is also -1, the behavior should be the same for > that situation. We could still retain the old behavior if desired, > but the decision seems arbitrary, so we take the simpler route. >=20 > Cc: Alexey Kardashevskiy > Cc: Shivaprasad G. Bhat > Signed-off-by: Michael Roth Applied to ppc-for-2.8, thanks. > --- > hw/ppc/spapr_pci.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) >=20 > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c > index 2a1ccf5..7cde30e 100644 > --- a/hw/ppc/spapr_pci.c > +++ b/hw/ppc/spapr_pci.c > @@ -1392,6 +1392,12 @@ static void spapr_phb_realize(DeviceState *dev, Er= ror **errp) > return; > } > =20 > + if (sphb->numa_node !=3D -1 && > + (sphb->numa_node >=3D MAX_NODES || !numa_info[sphb->numa_node].p= resent)) { > + error_setg(errp, "Invalid NUMA node ID for PCI host bridge"); > + return; > + } > + > sphb->dtbusname =3D g_strdup_printf("pci@%" PRIx64, sphb->buid); > =20 > namebuf =3D alloca(strlen(sphb->dtbusname) + 32); > @@ -1880,7 +1886,7 @@ int spapr_populate_pci_dt(sPAPRPHBState *phb, > } > =20 > /* Advertise NUMA via ibm,associativity */ > - if (nb_numa_nodes > 1) { > + if (phb->numa_node !=3D -1) { > _FDT(fdt_setprop(fdt, bus_off, "ibm,associativity", associativit= y, > sizeof(associativity))); > } --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYBtXhAAoJEGw4ysog2bOSfP8QAOSPW3KDHXxo2qDNQEG/6AZV MxBW8YkGmmA1JkBl4VlB1jJ/vrnBSlplJYQxu4vsIuF3vnBPcqx0n7yLgDZvIjVI Ychqf74tJ9ES/YA8vsRfM47qXvvAzlvSaW8IpKOnXUO4q7QASJpum7AV6BswecpE h+gOvonqN2bospLWoZTAGB+YMbJUqxIetmHz4kgQLjXKXsb+4FhSDlWMzQm3njil z90vM38rzFZ1La9ldGUVACjWLm6hCGQ6IdQQSToDFobxFvwj4DBC2PjnmuASv7FA +w9IpJxCcVFbV93S0YO+EdKqlJLh+iynheJ59gcNBd452K28qACK5+FLNC8ZIxUh q0rcNiq+nhS9fZDitXefO71xgERnF8Lr/DiulCijE5SrXPHBjYD0maWwu94t39c0 7AWWtVS3ZQ7/gEnnkXCeVK0UybzXDuhgom69MDyAKK19bODgC8gbshy1bS63Bi/t tGURE/SMX7nXPMvF6M0n4lH0YRn2P1MiwP++Fg2GX1jYE4lvnDVzWSE5pPshpCG2 4OOLREjVYCC3hVVParc19a3D+mBao0lYnkYxAxvPPQru3gTtl4kcpJm8x8dxw0Ut rARrIXrra82RGKzlfYfRgShwJxbram1InNFr4MlqknFaUkYs4s6I9MtiFBE2ke8C 5I146r/2kFSPq1Pg4W2A =iBX/ -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--