From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Spurious "NUMA placement failed, performance might be affected" message on ARM Date: Mon, 28 Apr 2014 12:25:11 +0200 Message-ID: <1398680711.6102.88.camel@Solace> References: <1398422242.18537.411.camel@kazak.uk.xensource.com> <1398678915.6102.69.camel@Solace> <1398679293.29700.30.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1857663599654040252==" Return-path: In-Reply-To: <1398679293.29700.30.camel@kazak.uk.xensource.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: Ian Campbell Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============1857663599654040252== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-pQPmjdmi4R4E5HH/4nf/" --=-pQPmjdmi4R4E5HH/4nf/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On lun, 2014-04-28 at 11:01 +0100, Ian Campbell wrote: > On Mon, 2014-04-28 at 11:55 +0200, Dario Faggioli wrote: > > While I wonder why that does not happen on ARM, a sensible solution > > would be to bail earlier, if we find only one NUMA node exist, for > > whatever arch. Would that be ok? If yes, I can arrange a patch pretty > > easily, I think. >=20 > I suppose if ARM is also reporting 1 node then for some reason this > check isn't hitting and moving it earlier won't help (not that it would > be a bad idea independently to optimise this a bit). >=20 Exactly. Honestly, I thought it was like that already, but I was evidently mis-remembering. I'll do that as soon as we will have sorted this out. > Perhaps ARM is reporting no NUMA nodes? The xl info -n output suggests > not but where else should I check. >=20 The output (which I removed) really looks similar to my non-NUMA x86 box. As per what to check, in libxl__get_numa_candidate(), if it enters this loop (and it should): for (comb_ok =3D comb_init(gc, &comb_iter, nr_suit_nodes, min_nodes= ); comb_ok; comb_ok =3D comb_next(comb_iter, nr_suit_nodes, min_nodes)) { The only reason why it does not get to the end of the first iter (and set cndt_found to 1) seems to be one of these if-s: /* If there is not enough memory in this combination, skip it * and go generating the next one... */ nodes_free_memkb =3D nodemap_to_free_memkb(ninfo, &nodemap); if (min_free_memkb && nodes_free_memkb < min_free_memkb) continue; /* And the same applies if this combination is short in cpus */ nodes_cpus =3D nodemap_to_nr_cpus(tinfo, nr_cpus, suitable_cpum= ap, &nodemap); if (min_cpus && nodes_cpus < min_cpus) continue; With only 1 node, the first one should really be false, or we shouldn't be here. The second is, I think, possible, but very unlikely (does your guest have more vCPUs than the host has pCPUs?). I'd be happy to have a look myself, but I don't have an ARM (cross) build environment ready right now... Perhaps this is the chance to get one, though... Do you want me to? (provided I can access that or a similar box) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-pQPmjdmi4R4E5HH/4nf/ 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.0.22 (GNU/Linux) iEYEABECAAYFAlNeLIcACgkQk4XaBE3IOsSFmQCeJVtsO8OYxoRb2+mCllyKPqCO CKgAnRg5EJwzq3Bd8lPczWIB90m6whTB =jdcc -----END PGP SIGNATURE----- --=-pQPmjdmi4R4E5HH/4nf/-- --===============1857663599654040252== 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 --===============1857663599654040252==--