From: Reinette Chatre <reinette.chatre@intel.com>
To: Chen Yu <yu.c.chen@intel.com>, <tony.luck@intel.com>
Cc: <tglx@kernel.org>, <bp@alien8.de>, <mingo@redhat.com>,
<dave.hansen@linux.intel.com>, <hpa@zytor.com>,
<fenghuay@nvidia.com>, <babu.moger@amd.com>,
<hongyu.ning@intel.com>, <chen.yu@linux.dev>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>,
Hongyu Ning <hongyu.ning@linux.intel.com>
Subject: Re: [PATCH v8 4/9] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online
Date: Mon, 28 Sep 2026 14:44:19 -0700 [thread overview]
Message-ID: <f79a0d30-2a3d-49dc-9632-b8a81e4fa7d8@intel.com> (raw)
In-Reply-To: <1299d05391a5095a151d6204a459d6ca0f431462.1789705667.git.yu.c.chen@intel.com>
Hi Chenyu,
On 9/17/26 9:50 PM, Chen Yu wrote:
> Reading LLC occupancy counters via MMIO requires the per-domain ERDT
> information, parsed from the ACPI ERDT table, to be reachable from the resctrl
> L3 monitoring domain. Nothing links the two yet, so the monitoring code cannot
> locate the MMIO registers of a domain.
Last sentence sets this change up as a bugfix when it is actually a preparatory patch.
>
> ERDT and CPUID enumerate CPU-to-L3-domain membership independently: CPUID leaf 4
> describes the L3 cache topology, while the firmware CACD sub-table lists the
> CPUs of each ERDT domain. Both views must agree on a CPU's L3 domain for that
> CPU to be monitored safely.
>
> When a CPU comes online, validate that firmware and CPUID agree on its L3 domain
> before adding it to any resctrl domain. Exclude the CPU from all resctrl domains
> on a mismatch because a topology inconsistency between ERDT and CPUID indicates
> a firmware defect that makes the CPU's domain placement unreliable for any
> resource. Otherwise attach the matching ERDT domain information to the L3
> monitoring domain so that monitoring data can be read via ERDT and its
> sub-tables.
>
> Suggested-by: Reinette Chatre <reinette.chatre@intel.com>
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> Tested-by: Hongyu Ning <hongyu.ning@linux.intel.com>
> ---
> arch/x86/kernel/cpu/resctrl/core.c | 16 ++++
> arch/x86/kernel/cpu/resctrl/erdt.c | 109 +++++++++++++++++++++++++
> arch/x86/kernel/cpu/resctrl/internal.h | 5 ++
> 3 files changed, 130 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> index 54cfdf12dfbb..3514d73a8056 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -34,6 +34,9 @@
> * the domain list must either take cpus_read_lock(), or rely on an RCU
> * read-side critical section, to avoid observing concurrent modification.
> * All writers take this mutex:
Above sentence ends with ":" since the definition used to follow it, adding
text below it breaks this reference.
> + *
> + * This mutex also protects the ERDT domain_info_list, which is modified when a
> + * CPU comes online.
Please read the comment that is above this added line ...
> */
> static DEFINE_MUTEX(domain_list_lock);
>
> @@ -564,6 +567,8 @@ static void l3_mon_domain_setup(int cpu, int id, struct rdt_resource *r, struct
> return;
> }
> list_add_tail_rcu(&d->hdr.list, add_pos);
> +
> + erdt_l3_mon_domain_setup(id, &d->hdr);
... the comment above domain_list_lock's definition explains how the domain list
is managed between resctrl fs and the architecture. Even though this change is made
with domain_list_lock held the above setup _after_ adding the domain to the RCU list
changes the resctrl monitoring domain _after_ it is made available to resctrl filesystem
via the RCU list.
This issue was also flagged by sashiko:
https://sashiko.dev/#/patchset/cover.1789705667.git.yu.c.chen%40intel.com?part=9
Apart from above I think this is the first hint that SNC and ERDT is not quite
integrated. Sashiko also found a couple of SNC vs ERDT sticky points.
For above, please consider that when SNC is enabled then resctrl sets the scope
of the L3 resource's monitoring domains to be RESCTRL_L3_NODE. That means that
@id parameter of l3_mon_domain_setup() could be the NUMA node ID, not L3 cache ID.
erdt_l3_mon_domain_setup() seems to assume an L3 cache ID and just searches for
a matching ERDT domain.
> }
>
> static void domain_add_cpu_mon(int cpu, struct rdt_resource *r)
> @@ -742,6 +747,17 @@ static int resctrl_arch_online_cpu(unsigned int cpu)
> struct rdt_resource *r;
>
> mutex_lock(&domain_list_lock);
> + /*
> + * A CPU whose ERDT and CPUID L3 domain views disagree is not added to
> + * any domain. resctrl_arch_offline_cpu() still tries to remove it when
> + * it goes offline and warns that no domain contains it. That warning is
> + * expected.
> + */
> + if (!erdt_cpu_valid(cpu)) {
> + mutex_unlock(&domain_list_lock);
> + return 0;
> + }
> +
> for_each_capable_rdt_resource(r)
> domain_add_cpu(cpu, r);
> mutex_unlock(&domain_list_lock);
> diff --git a/arch/x86/kernel/cpu/resctrl/erdt.c b/arch/x86/kernel/cpu/resctrl/erdt.c
> index 0dfe5eda166c..249ba547d7c8 100644
> --- a/arch/x86/kernel/cpu/resctrl/erdt.c
> +++ b/arch/x86/kernel/cpu/resctrl/erdt.c
> @@ -209,6 +209,115 @@ static __init bool parse_rmdd_table(struct acpi_subtbl_hdr_16 *rmdd_hdr)
> return false;
> }
>
> +bool erdt_cpu_valid(int cpu)
The function name "erdt_cpu_valid()" that returns a bool creates impression that it
just does a validity check without changing any state. This function does more than this.
How about something like "erdt_try_bind_cpu(int cpu)" and then the supporting text in changelog
can be "... validate and bind the CPU to its ERDT domain ...".
> +{
> + struct erdt_domain_info *d, *cpu_dom = NULL;
> + int dom_id;
> +
> + /* Without ERDT there is no firmware topology to disagree with. */
> + if (!erdt_enabled)
> + return true;
> +
> + dom_id = get_cpu_cacheinfo_id(cpu, RESCTRL_L3_CACHE);
> + if (dom_id < 0) {
> + pr_warn(FW_BUG "Can't find L3 id for CPU:%d\n", cpu);
> + return false;
> + }
> +
> + /*
> + * Find the erdt_domain_info that contains this CPU, then bind that ERDT
> + * domain to this CPU's L3 id. A CPU whose L3 id does not match the binding
> + * of its ERDT domain cannot be covered by resctrl.
> + *
> + * For example, the CACD sub-tables report:
> + * domain0: CPU0, CPU2, domain1: CPU1, CPU3
> + * while CPUID/cacheinfo reports the L3 cache is shared by:
> + * id0: CPU0, CPU1, id1: CPU2, CPU3
> + * With the CPUs coming online in order, CPU0 binds domain0 to L3 id0 and
> + * CPU3 binds domain1 to L3 id1, so CPU1 and CPU2 are not covered by
> + * resctrl.
> + */
Please move this comment block to be the comment of the entire function. It does not
have to be kernel-doc but it could borrow some of the style, for example, "this CPU"
can be @cpu to make it clear it refers to the function parameter.
The "With the CPUs coming online in order" also seems to describe whole function
and not just the snippet below it. With the function comment describing the example
entirely the smaller snippets within functions can refer to it more coherently.
> + list_for_each_entry(d, &domain_info_list, entry) {
> + if (cpumask_test_cpu(cpu, &d->cpu_mask)) {
> + cpu_dom = d;
> + break;
> + }
> + }
> +
> + if (!cpu_dom) {
> + pr_warn(FW_BUG "Cannot find the ERDT domain which has CPU%d\n", cpu);
> + return false;
> + }
> +
> + /* This ERDT domain is already bound to this CPU's L3 domain. */
> + if (cpu_dom->dom_id == dom_id)
> + return true;
> +
> + /*
> + * This ERDT domain is already bound to a different L3 domain. Rebinding it
> + * would leave two L3 domains reading the counters of one ERDT domain, so
> + * skip this CPU instead:
> + * When CPU2 is brought online, domain0 is found. But then it found that
> + * domain0's ID is 0, which is not -1(new domain), so CPU2 is ineligible.
> + */
> + if (cpu_dom->dom_id != -1) {
> + pr_warn(FW_BUG "CPU%d's id=%d not equal to CACD domain(%*pbl) id=%d, skip this CPU\n",
> + cpu, dom_id, cpumask_pr_args(&cpu_dom->cpu_mask), cpu_dom->dom_id);
> +
> + return false;
> + }
> +
> + /*
> + * A possible new binding. Check if another ERDT domain shares the same
> + * L3 id. If yes, this is a conflict and this CPU should not be considered
> + * by resctrl:
> + * When CPU1 is brought online, a new domain1 is found. But then it found that
Above is mixing tense
> + * domain0's ID is 0, which is the same as CPU1's dom_id, so CPU1 is ineligible.
> + */
> + list_for_each_entry(d, &domain_info_list, entry) {
> + if (d == cpu_dom)
> + continue;
> +
> + if (d->dom_id == dom_id) {
> + pr_warn(FW_BUG "CPU%d's id=%d is already used by CACD domain(%*pbl), skip this CPU\n",
> + cpu, dom_id, cpumask_pr_args(&d->cpu_mask));
> +
> + return false;
> + }
> + }
> +
> + /* Eligible new binding, assign the L3 id. */
> + cpu_dom->dom_id = dom_id;
> +
> + return true;
> +}
> +
> +/*
> + * Associate ERDT table information with this domain.
> + */
> +void erdt_l3_mon_domain_setup(int id, struct rdt_domain_hdr *hdr)
@id is unnecessary, function can just use hdr->id (but keep above comment about
@id not always being an L3 cache ID in mind).
> +{
> + struct rdt_hw_l3_mon_domain *hw_dom;
> + struct erdt_domain_info *d;
> +
> + if (!erdt_enabled)
> + return;
> +
> + hw_dom = resctrl_to_arch_mon_dom(container_of(hdr, struct rdt_l3_mon_domain, hdr));
> +
> + list_for_each_entry(d, &domain_info_list, entry) {
> + if (d->dom_id == id) {
> + /* Assign the ERDT information to hw_dom */
This comment is just duplicate of function comment and does not add any information
to the code it aims to describe.
> + if (hw_dom->d_info) {
Is this necessary? hw_dom has just been kzalloc'ed so it cannot have any value here
> + pr_warn(FW_BUG "Duplicated ERDT domains are mapped to an existing L3 domain\n");
> + return;
> + }
> + hw_dom->d_info = d;
> + return;
> + }
> + }
> +}
> +
> void erdt_exit(void)
> {
> struct erdt_domain_info *d, *tmp;
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index 156206088372..2e8fb36ad804 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -97,14 +97,19 @@ struct rdt_hw_ctrl_domain {
> * @arch_mbm_states: Per-event pointer to the MBM event's saved state.
> * An MBM event's state is an array of struct arch_mbm_state
> * indexed by RMID on x86.
> + * @d_info: ERDT table information of this domain
> *
> * Members of this structure are accessed via helpers that provide abstraction.
> */
> struct rdt_hw_l3_mon_domain {
> struct rdt_l3_mon_domain d_resctrl;
> struct arch_mbm_state *arch_mbm_states[QOS_NUM_L3_MBM_EVENTS];
> + const struct erdt_domain_info *d_info;
> };
>
> +bool erdt_cpu_valid(int cpu);
> +void erdt_l3_mon_domain_setup(int id, struct rdt_domain_hdr *hdr);
> +
Why did these two erdt related prototypes land here instead of with the
other erdt related prototypes?
> static inline struct rdt_hw_ctrl_domain *resctrl_to_arch_ctrl_dom(struct rdt_ctrl_domain *r)
> {
> return container_of(r, struct rdt_hw_ctrl_domain, d_resctrl);
Reinette
next prev parent reply other threads:[~2026-09-28 21:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 4:46 [PATCH v8 0/9] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
2026-09-18 4:48 ` [PATCH v8 1/9] x86/topology: Export topo_lookup_cpuid() for resctrl use Chen Yu
2026-09-18 4:48 ` [PATCH v8 2/9] x86/resctrl: Require 64-bit x86 for resctrl support Chen Yu
2026-09-28 21:21 ` Reinette Chatre
2026-09-18 4:49 ` [PATCH v8 3/9] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask for RMDD domains Chen Yu
2026-09-28 21:37 ` Reinette Chatre
2026-09-18 4:50 ` [PATCH v8 4/9] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online Chen Yu
2026-09-28 21:44 ` Reinette Chatre [this message]
2026-09-18 4:50 ` [PATCH v8 5/9] x86/resctrl: Parse ACPI CMRC table Chen Yu
2026-09-28 21:46 ` Reinette Chatre
2026-09-18 4:50 ` [PATCH v8 6/9] x86/resctrl: Refactor the monitor read function Chen Yu
2026-09-18 4:50 ` [PATCH v8 7/9] fs/resctrl: Do not invoke smp_processor_id() in preemptible context Chen Yu
2026-09-28 21:48 ` Reinette Chatre
2026-09-18 4:51 ` [PATCH v8 8/9] x86/resctrl: Introduce erdt_cpu_has() and erdt_support() Chen Yu
2026-09-28 21:49 ` Reinette Chatre
2026-09-18 4:51 ` [PATCH v8 9/9] x86/resctrl: Add MMIO-based LLC occupancy monitoring support Chen Yu
2026-09-28 21:54 ` 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=f79a0d30-2a3d-49dc-9632-b8a81e4fa7d8@intel.com \
--to=reinette.chatre@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=chen.yu@linux.dev \
--cc=dave.hansen@linux.intel.com \
--cc=fenghuay@nvidia.com \
--cc=hongyu.ning@intel.com \
--cc=hongyu.ning@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.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
all inboxes | Powered by JetHome®