From: Greg KH <gregkh@linuxfoundation.org>
To: Sandipan Das <sandipan.das@amd.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
stable@vger.kernel.org, Ravi Bangoria <ravi.bangoria@amd.com>,
Ananth Narayan <ananth.narayan@amd.com>
Subject: Re: [PATCH] perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains
Date: Thu, 22 Jan 2026 07:48:53 +0100 [thread overview]
Message-ID: <2026012245-endless-botanist-207d@gregkh> (raw)
In-Reply-To: <f337ed92d3e3d519ce4b5d4f23616053ca8a1726.1769063941.git.sandipan.das@amd.com>
On Thu, Jan 22, 2026 at 12:15:05PM +0530, Sandipan Das wrote:
> For DF and UMC PMUs, a single context is shared across all CPUs that are
> connected to the same Data Fabric (DF) instance. Currently, Socket ID is
> used to identify DF instances. This approach works for configurations
> having a single IO Die (IOD) but fails in the following cases.
> * Older Zen 1 processors, where each chiplet has its own DF instance
> instead of a single IOD.
> * Any configurations with multiple IODs in a single socket.
>
> Address this by using the Node ID available in ECX[7:0] of CPUID leaf
> 0x8000001e which is already provided by topology_amd_node_id(). Replace
> the use of topology_logical_package_id() with topology_amd_node_id() in
> order to correctly identify domains for context sharing.
>
> Fixes: 07888daa056e ("perf/x86/amd/uncore: Move discovery and registration")
> Signed-off-by: Sandipan Das <sandipan.das@amd.com>
> ---
> arch/x86/events/amd/uncore.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
> index 9293ce50574d..9a13a9f21d2f 100644
> --- a/arch/x86/events/amd/uncore.c
> +++ b/arch/x86/events/amd/uncore.c
> @@ -700,7 +700,7 @@ void amd_uncore_df_ctx_scan(struct amd_uncore *uncore, unsigned int cpu)
> info.split.aux_data = 0;
> info.split.num_pmcs = NUM_COUNTERS_NB;
> info.split.gid = 0;
> - info.split.cid = topology_logical_package_id(cpu);
> + info.split.cid = topology_amd_node_id(cpu);
>
> if (pmu_version >= 2) {
> ebx.full = cpuid_ebx(EXT_PERFMON_DEBUG_FEATURES);
> @@ -999,8 +999,8 @@ void amd_uncore_umc_ctx_scan(struct amd_uncore *uncore, unsigned int cpu)
> cpuid(EXT_PERFMON_DEBUG_FEATURES, &eax, &ebx.full, &ecx, &edx);
> info.split.aux_data = ecx; /* stash active mask */
> info.split.num_pmcs = ebx.split.num_umc_pmc;
> - info.split.gid = topology_logical_package_id(cpu);
> - info.split.cid = topology_logical_package_id(cpu);
> + info.split.gid = topology_amd_node_id(cpu);
> + info.split.cid = topology_amd_node_id(cpu);
> *per_cpu_ptr(uncore->info, cpu) = info;
> }
>
> --
> 2.43.0
>
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
prev parent reply other threads:[~2026-01-22 6:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 6:45 [PATCH] perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains Sandipan Das
2026-01-22 6:48 ` Greg KH [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=2026012245-endless-botanist-207d@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ananth.narayan@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=stable@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.