From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: Spurious "NUMA placement failed,
 performance might be affected" message on ARM
Date: Mon, 28 Apr 2014 11:55:15 +0200
Message-ID: <1398678915.6102.69.camel@Solace>
References: <1398422242.18537.411.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4714616208280391108=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1398422242.18537.411.camel@kazak.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

--===============4714616208280391108==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-F9zyySXUTc5NIUgKz4nK"

--=-F9zyySXUTc5NIUgKz4nK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On ven, 2014-04-25 at 11:37 +0100, Ian Campbell wrote:
> Hi Dario,
>=20
> When starting a guest on ARM I'm seeing (with no additional verbosity):
>         libxl: notice: libxl_numa.c:494:libxl__get_numa_candidate: NUMA p=
lacement failed, performance might be affected
>=20
> Which is a bit strong for a non-NUMA system.
>=20
Indeed.

> Is there some hypercall we need to stub out or return -ENOSYS from to
> cause this function to decide that this is not a NUMA system?
>=20
> Does the same message occur on non-NUMA x86 systems?
>=20
The message is printed inside libxl__get_numa_candidate() if no suitable
placement candidate is found. It does not happen on x86 non-NUMA boxes
as what happens there is that there is only 1 node, so the set of
possible combinations of nodes is made up of only one element, which is
deemed to be the best possible solution very quickly.

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.

For figuring out why the different behavior... Do you have the output of
`xl info -n' on that box handy, by any chance?

Regards,
Dario


--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-F9zyySXUTc5NIUgKz4nK
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)

iEYEABECAAYFAlNeJYMACgkQk4XaBE3IOsRpVACfXggI7C/eNRbiB5w4hEkakCCn
nYUAoJJBZzVW+B+J7EF+dI1c5tO4f/PE
=r+b0
-----END PGP SIGNATURE-----

--=-F9zyySXUTc5NIUgKz4nK--


--===============4714616208280391108==
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

--===============4714616208280391108==--