From: Tony Luck <tony.luck@intel.com>
To: Peter Newman <peternewman@google.com>
Cc: "Yu, Fenghua" <fenghua.yu@intel.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
"x86@kernel.org" <x86@kernel.org>,
Shaopeng Tan <tan.shaopeng@fujitsu.com>,
James Morse <james.morse@arm.com>,
Jamie Iles <quic_jiles@quicinc.com>,
Babu Moger <babu.moger@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"patches@lists.linux.dev" <patches@lists.linux.dev>,
"Eranian, Stephane" <eranian@google.com>
Subject: Re: [PATCH v2 7/7] x86/resctrl: Determine if Sub-NUMA Cluster is enabled and initialize.
Date: Fri, 23 Jun 2023 13:20:38 -0700 [thread overview]
Message-ID: <ZJX+lmQTUEujF88U@agluck-desk3> (raw)
In-Reply-To: <CALPaoCiaknUMSU4CunSQrRP=WS8DAbToVo5jibh8TaWNZXGMbQ@mail.gmail.com>
On Fri, Jun 23, 2023 at 05:19:37PM +0200, Peter Newman wrote:
> Hi Tony,
>
> On Thu, Jun 22, 2023 at 6:02 PM Luck, Tony <tony.luck@intel.com> wrote:
> >
> > > Unfortunately I'm not getting as good of results with the new series.
> > > The main difference seems to be updating the 0xca0 MSR instead of
> > > applying the offset to PQR_ASSOC.
> >
> > I think I may have reversed the actions to update the MSR in one of
> > my refactor/rebase. The comment here is correct, but that's not
> > what the code is doing :-(
> >
> > Can you swap the bodies of these two functions and retest?
>
> It's a small improvement, but still not great. Still only node 0
> giving believable results, but at least no more empty results from the
> second package.
>
> I poked around in /proc/kcore and noticed that my snc_ways is still 1, though.
Below is the patch I applied to reverse the add/remove package actions
together with some debug to make double sure SNC is being detected as
I expect and the right actions taken.
When booting the debug messages say:
[ 9.458624] resctrl: SNC_ways = 2
[ 9.458801] resctrl: CPU0: set MSR_RMID_SNC_CONFIG to 0x0
[ 9.461986] resctrl: CPU56: set MSR_RMID_SNC_CONFIG to 0x0
which is all good and correct.
For my tests I have a memory hog process that loops on a memcpy()
of 100 MBytes to generate enough traffic to be totally obvious when
looking at the mbm counters.
Test 1: I used taskset(1) to start a copy on the first CPU of node0
and checked the MBM counters. Both local and remote showed around
25 GB/s on node 0. Killed this process.
Tests 2, 3, 4: Same as 1, but started the process on first CPU of node
1, 2, 3. Same result. Around 25 GB/s appeared in the MBM counts for
the right node in each cycle.
Test 5: Started on node0, then periodically used taskset to bind the
running process onto a CPU on another node. It looks like Linux
migrates the memory for the job shortly after the affinity of the
process is changed. A few seconds after each process migration, the
MBM counters reflect traffic on the node that is the new home of the
process.
-Tony
From 414341db02cd51daaf4a9ea8bd68b22a23cf4b59 Mon Sep 17 00:00:00 2001
From: Tony Luck <tony.luck@intel.com>
Date: Fri, 23 Jun 2023 08:57:57 -0700
Subject: [PATCH] Fix inverted SNC enable/disable MSR writes. Add some debug
too.
---
arch/x86/kernel/cpu/resctrl/core.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
index 869cfb46e8e4..e66b2b84fe6f 100644
--- a/arch/x86/kernel/cpu/resctrl/core.c
+++ b/arch/x86/kernel/cpu/resctrl/core.c
@@ -546,18 +546,20 @@ static void snc_add_pkg(void)
{
u64 msrval;
- rdmsrl(MSR_RMID_SNC_CONFIG, msrval);
- msrval |= BIT_ULL(0);
- wrmsrl(MSR_RMID_SNC_CONFIG, msrval);
-}
-
-static void snc_remove_pkg(void)
-{
- u64 msrval;
-
rdmsrl(MSR_RMID_SNC_CONFIG, msrval);
msrval &= ~BIT_ULL(0);
wrmsrl(MSR_RMID_SNC_CONFIG, msrval);
+pr_info("CPU%d: set MSR_RMID_SNC_CONFIG to 0x%llx\n", raw_smp_processor_id(), msrval);
+}
+
+static void snc_remove_pkg(void)
+{
+ u64 msrval;
+
+ rdmsrl(MSR_RMID_SNC_CONFIG, msrval);
+ msrval |= BIT_ULL(0);
+ wrmsrl(MSR_RMID_SNC_CONFIG, msrval);
+pr_info("CPU%d: set MSR_RMID_SNC_CONFIG to 0x%llx\n", raw_smp_processor_id(), msrval);
}
/*
@@ -987,6 +989,7 @@ static __init int find_snc_ways(void)
if (ret > 1)
rdt_resources_all[RDT_RESOURCE_PKG].r_resctrl.pkg_actions = true;
+pr_info("SNC_ways = %d\n", ret);
return ret;
}
--
2.40.1
next prev parent reply other threads:[~2023-06-23 20:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 17:39 [PATCH v2 0/7] x86/resctrl: Add support for Sub-NUMA cluster (SNC) systems Tony Luck
2023-06-21 17:40 ` [PATCH v2 1/7] x86/resctrl: Refactor in preparation for node-scoped resources Tony Luck
2023-06-21 17:40 ` [PATCH v2 2/7] x86/resctrl: Remove hard code of RDT_RESOURCE_L3 in monitor.c Tony Luck
2023-06-21 17:40 ` [PATCH v2 3/7] x86/resctrl: Add a new node-scoped resource to rdt_resources_all[] Tony Luck
2023-06-21 17:40 ` [PATCH v2 4/7] x86/resctrl: Add code to setup monitoring at L3 or NODE scope Tony Luck
2023-06-21 17:40 ` [PATCH v2 5/7] x86/resctrl: Add package scoped resource Tony Luck
2023-06-29 7:38 ` Shaopeng Tan (Fujitsu)
2023-06-21 17:40 ` [PATCH v2 6/7] x86/resctrl: Update documentation with Sub-NUMA cluster changes Tony Luck
2023-06-21 17:52 ` Randy Dunlap
2023-06-21 17:40 ` [PATCH v2 7/7] x86/resctrl: Determine if Sub-NUMA Cluster is enabled and initialize Tony Luck
2023-06-22 14:25 ` Peter Newman
2023-06-22 16:01 ` Luck, Tony
2023-06-23 15:19 ` Peter Newman
2023-06-23 20:20 ` Tony Luck [this message]
2023-06-26 12:18 ` Peter Newman
2023-06-26 12:47 ` Peter Newman
2023-06-26 15:52 ` Luck, Tony
2023-06-26 16:20 ` Luck, Tony
2023-06-28 13:43 ` Peter Newman
2023-06-29 7:34 ` Shaopeng Tan (Fujitsu)
2023-06-29 15:56 ` Luck, Tony
2023-06-29 8:13 ` [PATCH v2 0/7] x86/resctrl: Add support for Sub-NUMA cluster (SNC) systems Shaopeng Tan (Fujitsu)
2023-06-29 16:05 ` Luck, Tony
2023-07-11 20:50 ` Reinette Chatre
2023-07-11 21:23 ` Tony Luck
2023-07-11 21:55 ` Reinette Chatre
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=ZJX+lmQTUEujF88U@agluck-desk3 \
--to=tony.luck@intel.com \
--cc=babu.moger@amd.com \
--cc=corbet@lwn.net \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=james.morse@arm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=peternewman@google.com \
--cc=quic_jiles@quicinc.com \
--cc=reinette.chatre@intel.com \
--cc=tan.shaopeng@fujitsu.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;
as well as URLs for NNTP newsgroup(s).