From: Peter Zijlstra <peterz@infradead.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"rientjes@google.com" <rientjes@google.com>,
"imammedo@redhat.com" <imammedo@redhat.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
"prarit@redhat.com" <prarit@redhat.com>,
"toshi.kani@hp.com" <toshi.kani@hp.com>,
"brice.goglin@gmail.com" <brice.goglin@gmail.com>,
"hpa@linux.intel.com" <hpa@linux.intel.com>,
"mingo@kernel.org" <mingo@kernel.org>
Subject: Re: [PATCH] x86, sched: allow topolgies where NUMA nodes share an LLC
Date: Thu, 8 Jun 2017 22:20:41 +0200 [thread overview]
Message-ID: <20170608202041.GE8337@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F612CC19A@ORSMSX114.amr.corp.intel.com>
On Thu, Jun 08, 2017 at 08:08:31PM +0000, Luck, Tony wrote:
> > What does? That does sound broken. How can a cache domain sanely span
> > memory controllers?
>
> Think "cluster on die" with cores on the socket split into two clusters, but still sharing LLC.
The thing is, cluster-on-die works with the current code, and therefore
seems to modify the SRAT an CPUID information in a consistent manner.
Which in turn seems to suggest the LLC really is split for
cluster-on-die.
This is something new, and the Changelog is absolute crap for not
explaining _anything_.
So while SRAT seems to invent new nodes, the CPUID topology bits still
describes the full LLC, now shared across nodes.
Is this accurate?, do these nodes, as described by SRAT, actually have a
memory controller each? And is the LLC still fully integrated across the
nodes? If so, we need to go fix the scheduler domain topology to put a
cache domain across nodes (which is going to be painful).
Just making the warning go away and not explaining things sucks.
prev parent reply other threads:[~2017-06-08 20:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-08 19:39 [PATCH] x86, sched: allow topolgies where NUMA nodes share an LLC Dave Hansen
2017-06-08 20:00 ` Peter Zijlstra
2017-06-08 20:08 ` Luck, Tony
2017-06-08 20:20 ` Peter Zijlstra [this message]
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=20170608202041.GE8337@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=brice.goglin@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@linux.intel.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=prarit@redhat.com \
--cc=rientjes@google.com \
--cc=tim.c.chen@linux.intel.com \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=toshi.kani@hp.com \
/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