xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: Spurious "NUMA placement failed, performance might be affected" message on ARM
Date: Mon, 28 Apr 2014 11:55:15 +0200	[thread overview]
Message-ID: <1398678915.6102.69.camel@Solace> (raw)
In-Reply-To: <1398422242.18537.411.camel@kazak.uk.xensource.com>


[-- Attachment #1.1: Type: text/plain, Size: 1518 bytes --]

On ven, 2014-04-25 at 11:37 +0100, Ian Campbell wrote:
> Hi Dario,
> 
> When starting a guest on ARM I'm seeing (with no additional verbosity):
>         libxl: notice: libxl_numa.c:494:libxl__get_numa_candidate: NUMA placement failed, performance might be affected
> 
> Which is a bit strong for a non-NUMA system.
> 
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?
> 
> Does the same message occur on non-NUMA x86 systems?
> 
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


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


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2014-04-28  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 10:37 Spurious "NUMA placement failed, performance might be affected" message on ARM Ian Campbell
2014-04-28  9:55 ` Dario Faggioli [this message]
2014-04-28 10:01   ` Ian Campbell
2014-04-28 10:25     ` Dario Faggioli
2014-04-28 11:30     ` Ian Campbell
2014-04-28 12:15       ` Andrew Cooper
2014-04-29 15:36         ` Dario Faggioli
2014-04-28 12:23       ` Dario Faggioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1398678915.6102.69.camel@Solace \
    --to=dario.faggioli@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).