From: Dave Hansen <dave@sr71.net>
To: a.p.zijlstra@chello.nl
Cc: mingo@kernel.org, hpa@linux.intel.com, brice.goglin@gmail.com,
bp@alien8.de, linux-kernel@vger.kernel.org,
Dave Hansen <dave@sr71.net>,
dave.hansen@linux.intel.com
Subject: [RFC][PATCH 5/6] sched: keep MC domain from crossing nodes OR packages
Date: Wed, 17 Sep 2014 15:33:18 -0700 [thread overview]
Message-ID: <20140917223318.22A46909@viggo.jf.intel.com> (raw)
In-Reply-To: <20140917223310.026BCC2C@viggo.jf.intel.com>
From: Dave Hansen <dave.hansen@linux.intel.com>
The MC (MultiCore) sched domain was originally intended to
represent the groupings of cores in a multi-core CPU.
The sched domains code has essentially two kinds of topology
levels:
1. CPU levels, like hyperthreads or cores that share cache
2. NUMA levels derived from the system's NUMA topology
The domains are built by first going through the CPU levels, then
through the NUMA levels. However, we now have at least two
instances of systems where a single CPU "package" has multiple
NUMA nodes.
To fix this, we redefine the multi-core level. Previously, it
was defined as stopping at the CPU package. Now, we define it as
grouping similar CPUs that are both in the same package *and*
that have the same access to some set of memory. Essentially an
MC group must be in the same package *and* be on the same NUMA
node.
This does no harm because there is a NUMA precisely at the level
which "MC" used to represent.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
b/arch/x86/kernel/smpboot.c | 26 ++++++++++++++++++++------
1 file changed, 20 insertions(+), 6 deletions(-)
diff -puN arch/x86/kernel/smpboot.c~keep-mc-from-crossing-nodes-or-package arch/x86/kernel/smpboot.c
--- a/arch/x86/kernel/smpboot.c~keep-mc-from-crossing-nodes-or-package 2014-09-17 15:28:58.226604751 -0700
+++ b/arch/x86/kernel/smpboot.c 2014-09-17 15:28:58.230604935 -0700
@@ -345,13 +345,27 @@ static bool match_llc(struct cpuinfo_x86
static bool match_mc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
{
- if (c->phys_proc_id == o->phys_proc_id) {
- if (cpu_has(c, X86_FEATURE_AMD_DCM))
- return true;
+ /*
+ * Do not allow a multi-core group
+ * ouside of a package.
+ */
+ if (c->phys_proc_id != o->phys_proc_id)
+ return false;
- return topology_sane(c, o, "mc");
- }
- return false;
+ /*
+ * Do not allow a multi-core group
+ * ouside of a NUMA node.
+ */
+ if (cpu_to_node(c->cpu_index) !=
+ cpu_to_node(o->cpu_index))
+ return false;
+
+ /*
+ * This pretty much repeats the NUMA node
+ * check above, but leave it here for
+ * consistency.
+ */
+ return topology_sane(c, o, "mc");
}
static bool match_pkg(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
_
next prev parent reply other threads:[~2014-09-17 22:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 22:33 [RFC][PATCH 0/6] fix topology for multi-NUMA-node CPUs Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 1/6] topology: rename topology_core_cpumask() to topology_package_cpumask() Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 2/6] x86: introduce cpumask specifically for the package Dave Hansen
2014-09-18 14:57 ` Peter Zijlstra
2014-09-17 22:33 ` [RFC][PATCH 3/6] x86: use package_map instead of core_map for sysfs Dave Hansen
2014-09-17 22:33 ` [RFC][PATCH 4/6] sched: eliminate "DIE" domain level when NUMA present Dave Hansen
2014-09-18 17:28 ` Peter Zijlstra
2014-09-17 22:33 ` Dave Hansen [this message]
2014-09-17 22:33 ` [RFC][PATCH 6/6] sched: consolidate config options Dave Hansen
2014-09-18 17:29 ` Peter Zijlstra
2014-09-19 19:15 ` Dave Hansen
2014-09-19 23:03 ` Peter Zijlstra
2014-09-18 7:45 ` [RFC][PATCH 0/6] fix topology for multi-NUMA-node CPUs Borislav Petkov
[not found] ` <CAOjmkp8EGO0jicmdO=p6ATHz-hUJmWb+xoBLjOdLBUwwGzyhhg@mail.gmail.com>
2014-09-22 15:54 ` Aravind Gopalakrishnan
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=20140917223318.22A46909@viggo.jf.intel.com \
--to=dave@sr71.net \
--cc=a.p.zijlstra@chello.nl \
--cc=bp@alien8.de \
--cc=brice.goglin@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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
Powered by JetHome