From: Peter Zijlstra <peterz@infradead.org>
To: Josef Bacik <jbacik@fb.com>
Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH] x86: don't check numa topology when setting up core siblings
Date: Mon, 28 Jul 2014 18:39:09 +0200 [thread overview]
Message-ID: <20140728163909.GR19379@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1406564919-19283-1-git-send-email-jbacik@fb.com>
[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]
On Mon, Jul 28, 2014 at 12:28:39PM -0400, Josef Bacik wrote:
> We have these processors with this Cluster on die feature which shares numa
> nodes between cores on different sockets.
Uhm, what?! I know AMD has chips that have two nodes per package, but
what you say doesn't make sense.
> When booting up we were getting this
> error with COD enabled (this is a 4 socket 12 core per CPU box)
>
> smpboot: Booting Node 0, Processors #1 #2 #3 #4 #5 OK
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/smpboot.c:324 topology_sane.isra.2+0x6f/0x82()
> sched: CPU #6's mc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency.
> smpboot: Booting Node 1, Processors #6
> Modules linked in:
> CPU: 6 PID: 0 Comm: swapper/6 Not tainted 3.10.39-31_fbk12_01013_ga2de9bf #1
> Hardware name: Quanta Leopard-DDR3/Leopard-DDR3, BIOS F06_3A03.08 05/24/2014
> ffffffff810971d4 ffff8802748d3e48 0000000000000009 ffff8802748d3df8
> ffffffff815bba59 ffff8802748d3e38 ffffffff8103b02b ffff8802748d3e28
> 0000000000000001 000000000000b010 0000000000012580 0000000000000000
> Call Trace:
> [<ffffffff810971d4>] ? print_modules+0x54/0xa0
> [<ffffffff815bba59>] dump_stack+0x19/0x1b
> [<ffffffff8103b02b>] warn_slowpath_common+0x6b/0xa0
> [<ffffffff8103b101>] warn_slowpath_fmt+0x41/0x50
> [<ffffffff815ada56>] topology_sane.isra.2+0x6f/0x82
> [<ffffffff815ade23>] set_cpu_sibling_map+0x380/0x42c
> [<ffffffff815adfe7>] start_secondary+0x118/0x19a
> ---[ end trace 755dbfb52f761180 ]---
> #7 #8 #9 #10 #11 OK
>
> and then the /proc/cpuinfo would show "cores: 6" instead of "cores: 12" because
> the sibling map doesn't get set right.
Yeah, looks like your topology setup is wrecked alright.
> This patch fixes this.
No, as you say, this patch just makes the warning go away, you still
have a royally fucked topology setup.
> Now I realize
> this is probably not the correct fix but I'm an FS guy and I don't understand
> this stuff.
:-)
> Looking at the cpuflags with COD on and off there appears to be no
> difference. The only difference I can spot is with it on we have 4 numa nodes
> and with it off we have 2, but that seems like a flakey check at best to add.
> I'm open to suggestions on how to fix this properly. Thanks,
Got a link that explains this COD nonsense?
Google gets me something about Intel SSSC, but nothing that explains
your BIOS? knob.
I suspect your BIOS is buggy and doesn't properly modify the CPUID
topology data.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-07-28 16:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 16:28 [RFC] [PATCH] x86: don't check numa topology when setting up core siblings Josef Bacik
2014-07-28 16:39 ` Peter Zijlstra [this message]
2014-07-28 17:23 ` Josef Bacik
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=20140728163909.GR19379@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=hpa@zytor.com \
--cc=jbacik@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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