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 12:25:11 +0200	[thread overview]
Message-ID: <1398680711.6102.88.camel@Solace> (raw)
In-Reply-To: <1398679293.29700.30.camel@kazak.uk.xensource.com>


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

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.
> 
> 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).
> 
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.
> 
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 = comb_init(gc, &comb_iter, nr_suit_nodes, min_nodes);
             comb_ok;
             comb_ok = 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 = 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 = nodemap_to_nr_cpus(tinfo, nr_cpus, suitable_cpumap,
                                            &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

-- 
<<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 10:25 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
2014-04-28 10:01   ` Ian Campbell
2014-04-28 10:25     ` Dario Faggioli [this message]
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=1398680711.6102.88.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).