From: Dave Hansen <dave.hansen@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
Alison Schofield <alison.schofield@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>, Tony Luck <tony.luck@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
David Rientjes <rientjes@google.com>,
Igor Mammedov <imammedo@redhat.com>,
Prarit Bhargava <prarit@redhat.com>,
brice.goglin@gmail.com, x86@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC
Date: Thu, 29 Mar 2018 06:45:12 -0700 [thread overview]
Message-ID: <aa369ee2-6557-8e3f-e2b4-d347b27825a6@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1803291505590.1477@nanos.tec.linutronix.de>
On 03/29/2018 06:16 AM, Thomas Gleixner wrote:
>> This is OK at least on the hardware we are immediately concerned about
>> because the LLC sharing happens at both the slice and at the package
>> level, which are also NUMA boundaries.
> So that addresses the scheduler interaction, but it still leaves the
> information in the sysfs files unchanged. See cpu/intel_cacheinfo.c. There
> are applications which use that information so it should be correct.
Were you thinking of shared_cpu_list/map? The information in there is
correct for core->off-package access. It is not correct for
core->on-package access, unless that access is perfectly interleaved
across both package "slices".
We could try to add an attribute or two to clarify this situation. But,
similar to the CPUID leaves, I don't think we actually have a precise
way to describe the way the cache actually works here.
next prev parent reply other threads:[~2018-03-29 13:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 0:00 [PATCH v3] x86,sched: allow topologies where NUMA nodes share an LLC Alison Schofield
2018-03-29 13:16 ` Thomas Gleixner
2018-03-29 13:45 ` Dave Hansen [this message]
2018-03-29 13:57 ` Peter Zijlstra
2018-03-29 13:47 ` Peter Zijlstra
2018-03-29 14:34 ` Dave Hansen
2018-03-29 16:09 ` Peter Zijlstra
2018-03-29 16:25 ` Dave Hansen
2018-03-29 16:29 ` Luck, Tony
2018-03-29 14:37 ` Dave Hansen
2018-03-29 14:55 ` Peter Zijlstra
2018-03-30 3:20 ` kbuild test robot
2018-03-30 17:34 ` Alison Schofield
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=aa369ee2-6557-8e3f-e2b4-d347b27825a6@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=alison.schofield@intel.com \
--cc=bp@alien8.de \
--cc=brice.goglin@gmail.com \
--cc=hpa@linux.intel.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=prarit@redhat.com \
--cc=rientjes@google.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=tony.luck@intel.com \
--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