All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <yu.c.chen@intel.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: <tony.luck@intel.com>, <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>,
	"Anil S Keshavamurthy" <anil.s.keshavamurthy@intel.com>,
	Hongyu Ning <hongyu.ning@linux.intel.com>
Subject: Re: [PATCH v9 03/12] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask per RMD
Date: Tue, 27 Oct 2026 16:14:01 +0800	[thread overview]
Message-ID: <auBdSeJUJqKx6MGu@chenyu-dev> (raw)
In-Reply-To: <92ca4378-0bce-4638-826b-9ce23a1b5cb2@intel.com>

Hi Reinette,

On Fri, Oct 23, 2026 at 04:50:24PM -0700, Reinette Chatre wrote:
> Hi Chenyu,
> 
> On 10/13/26 7:58 PM, Chen Yu wrote:
> > Enhanced RDT (ERDT) exposes per-domain MMIO registers that resctrl needs
> > in order to read hardware monitoring counters on the upcoming MMIO-based
> > path. The kernel discovers this hardware through a single per-platform
> > ERDT ACPI table.
> > 
> > Each Resource Management Domain Description (RMDD) sub-table within the
> > ERDT table represents one resource management domain (RMD). When
> > RMDD_FLAG_CPU_L3_DOMAIN is set, it identifies the domain as a CPU-scoped
> > L3 domain. The MMIO base of the domain's CMT counters is carried by the
> > RMDD's Cache Monitoring Registers for CPU Agents Description (CMRC)
> 
> Please drop this sentency about CMRC table and CMT counters, it is unrelated
> to this patch and distracting from what it aims to achieve.
>

OK, will do.

> > Changes since v8:
> > - Rename the subject from "... save CACD cpumask for RMDD domains" to
> >   "... save CACD cpumask per RMD". (Reinette Chatre)
> > - Rewrite the changelog to lead with the motivation, drop the duplicated
> >   first paragraph, and add a diagram of the ERDT/RMDD/CACD hierarchy.
> >   (Reinette Chatre)
> 
> Did I really ask for a diagram?

No, you did not. I added this diagram to help describe the hierarchy
more clearly.

> It is nice but I think it highlights
> how the various domain IDs can be confusing. The diagram shows domain_id at
> two different scope which raises this importance of these values but these
> domain IDs are not actually (apart from some debugging) used in this patch.
>

OK, will remove domain_id from both the RMDD and the CACD tables.

> > diff --git a/arch/x86/kernel/cpu/resctrl/Makefile b/arch/x86/kernel/cpu/resctrl/Makefile
> > index 273ddfa30836..a975c73e273e 100644
> > --- a/arch/x86/kernel/cpu/resctrl/Makefile
> > +++ b/arch/x86/kernel/cpu/resctrl/Makefile
> > @@ -1,6 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_X86_CPU_RESCTRL)		+= core.o rdtgroup.o monitor.o
> >  obj-$(CONFIG_X86_CPU_RESCTRL)		+= ctrlmondata.o
> > +obj-$(CONFIG_X86_CPU_RESCTRL)		+= erdt.o
> 
> nit: erdt.o could just be added to the line with ctrlmondata.o?
>

OK, will change it.

> >  obj-$(CONFIG_X86_CPU_RESCTRL_INTEL_AET)	+= intel_aet.o
> >  obj-$(CONFIG_RESCTRL_FS_PSEUDO_LOCK)	+= pseudo_lock.o
> >  
> 
> ...
> 
> > +/*
> > + * The minimal max_rmid of different domains. Using minimal is to avoid the domain with
> > + * small RMID accessing an invalid RMID.
> 
> Going back and forth between minimum and maximum is confusing.
> Could this comment just be simplified to "Largest RMID that is valid in every ERDT domain."?
>

OK, will change it.

> > +static __init bool cacd_init(struct acpi_subtbl_hdr_16 *subtbl,
> > +			     struct erdt_domain_info *domain_info)
> > +{
> > +	struct acpi_erdt_cacd *cacd = (struct acpi_erdt_cacd *)subtbl;
> > +	unsigned int num_ids;
> > +	int cpu;
> > +
> > +	if (cacd->header.length < struct_size(cacd, X2APICIDS, 1)) {
> > +		pr_warn(FW_BUG "Invalid x2APIC ID CACD table\n");
> > +		return false;
> > +	}
> > +
> > +	num_ids = (cacd->header.length - sizeof(*cacd)) / sizeof(cacd->X2APICIDS[0]);
> > +
> > +	for (unsigned int i = 0; i < num_ids; i++) {
> > +		cpu = topo_lookup_cpuid(cacd->X2APICIDS[i]);
> > +		/* Skip CPUs not in the possible mask, e.g. excluded by nr_cpus= */
> > +		if (cpu < 0)
> > +			continue;
> 
> With this new change it is possible for cacd_init() to return "true" without
> finding any matching CPUs. A "true" return would result in an ERDT domain without
> any CPUs added to the domain_info_list. Should such a domain rather be skipped?
>

I see, before adding the ERDT domain into the list, will check if that
domain has any CPUs, I've changed it to something like below:

	/* After iterating the RMDD subtables(including CACD) */

	/* Skip an RMDD without any CPU, for example, all excluded by nr_cpus= */
	if (cpumask_empty(&domain_info->cpu_mask)) {
		cleanup_one_domain(domain_info);
		return true;
	}

	if (!valid_subtbl_mask) {
	...

	list_add(&domain_info->entry, &domain_info_list);

> > +
> > +	domain_info->dom_id = ERDT_DOMAIN_ID_UNSET;
> > +
> > +	domain_info->base[ERDT_MMIO_RMDD_CREG] =
> > +		erdt_ioremap(rmdd->creg_base, rmdd->creg_size, "RMDD ctrl base");
> > +	if (!domain_info->base[ERDT_MMIO_RMDD_CREG])
> > +		goto cleanup;
> > +
> > +	for (subtbl = (void *)rmdd + sizeof(*rmdd);
> > +	     subtbl_valid((void *)rmdd + rmdd->header.length, subtbl);
> > +	     subtbl = next_subtbl(subtbl)) {
> > +		switch (subtbl->type) {
> > +		/* An RMDD table has one or more CACD sub-table(s) */
> > +		case ACPI_ERDT_TYPE_CACD:
> > +			if (!cacd_init(subtbl, domain_info))
> > +				goto cleanup;
> > +
> > +			subtbl_mask |= BIT(ACPI_ERDT_TYPE_CACD);
> 
> Should this bit be set if no valid CPUs found (in which case cacd_init()
> returns true)?
>

I kept setting the bit, because it records which sub-table types firmware
provides, which is what the "same set of sub-tables" check compares. An RMDD
without any CPU is now dropped right after the sub-table walk, before
valid_subtbl_mask is set or compared, so it cannot affect that check.

> > +			break;
> > +		default:
> > +			break;
> > +		}
> > +	}
> > +
> > +	if (!subtbl_mask)
> > +		goto cleanup;
> 
> How about a check here to ensure that the domain actually has CPUs before adding it
> to the list? If so, it may be easier to map ERDT_MMIO_RMDD_CREG *after* the RMDD
> has been determined to have some valid CPUs?
>

Yes, I change it a little bit to:

/* A CPU-based L3 RMDD must have at least one CACD sub-table */
if (!(subtbl_mask & BIT(ACPI_ERDT_TYPE_CACD))) {
	pr_warn(FW_BUG "RMDD %u has no CACD sub-table\n", rmdd->domain_id);
	goto cleanup;
}

/* Quietly skip an RMDD without any CPU, for example, all excluded by nr_cpus= */
if (cpumask_empty(&domain_info->cpu_mask)) {
	cleanup_one_domain(domain_info);
	return true;
}

if (!valid_subtbl_mask) {
...

list_add(&domain_info->entry, &domain_info_list);

> > +	return false;
> > +}
> > +
> > +void erdt_exit(void)
> > +{
> > +	struct erdt_domain_info *d, *tmp;
> > +
> > +	list_for_each_entry_safe(d, tmp, &domain_info_list, entry) {
> > +		list_del(&d->entry);
> > +		cleanup_one_domain(d);
> > +	}
> > +	erdt_enabled = false;
> > +	valid_subtbl_mask = 0;
> > +	first_rmdd_domain_id = 0;
> > +	erdt_max_rmid = 0;
> 
> The ERDT API seems to expose these globals via helpers that resctrl can call
> at any time irrespective of whether erdt_enabled is true or not. For example, 
> patch #7 adds a new global erdt_scale, and makes it available via erdt_get_scale()
> without any additional checks. If this is the plan then it is very important to
> ensure all globals are reset here and it looks like erdt_scale is not added
> to this list when it is introduced.

Got it, thanks for pointing out, will add erdt_scale = 0 in patch #7.

> Also please consider checking if erdt is
> enabled to ensure a sane value is return from these helpers. Doing so may be
> an easier pattern for contributions to follow than to subtly require a reset
> here that is already missed in this series.
>

I see, will also add erdt_enabled check in every helper functions in subsequent patches.

thanks,
Chenyu

  reply	other threads:[~2026-10-27  8:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  2:56 [PATCH v9 00/12] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
2026-10-14  2:57 ` [PATCH v9 01/12] x86/topology: Export topo_lookup_cpuid() for resctrl use Chen Yu
2026-10-14  2:58 ` [PATCH v9 02/12] x86/resctrl: Require 64-bit x86 for resctrl support Chen Yu
2026-10-23 23:46   ` Reinette Chatre
2026-10-27  7:54     ` Chen Yu
2026-10-14  2:58 ` [PATCH v9 03/12] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask per RMD Chen Yu
2026-10-23 23:50   ` Reinette Chatre
2026-10-27  8:14     ` Chen Yu [this message]
2026-10-14  2:58 ` [PATCH v9 04/12] x86/resctrl: Do not enable ERDT when Sub-NUMA Cluster is enabled Chen Yu
2026-10-23 23:54   ` Reinette Chatre
2026-10-27  8:54     ` Chen Yu
2026-10-27 16:16       ` Reinette Chatre
2026-10-28  2:44         ` Chen Yu
2026-10-14  2:58 ` [PATCH v9 05/12] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online Chen Yu
2026-10-23 23:57   ` Reinette Chatre
2026-10-24  0:37     ` Reinette Chatre
2026-10-27 10:36     ` Chen Yu
2026-10-27 16:17       ` Reinette Chatre
2026-10-28  2:57         ` Chen Yu
2026-10-14  2:59 ` [PATCH v9 06/12] x86,fs/resctrl: Move resctrl_arch_round_mon_val() out of line Chen Yu
2026-10-23 23:59   ` Reinette Chatre
2026-10-27 10:39     ` Chen Yu
2026-11-03 20:38   ` Ben Horgan
2026-11-04  3:00     ` Chen Yu
2026-10-14  2:59 ` [PATCH v9 07/12] x86/resctrl: Add a global ERDT monitor scale Chen Yu
2026-10-24  0:02   ` Reinette Chatre
2026-10-27 10:53     ` Chen Yu
2026-10-14  2:59 ` [PATCH v9 08/12] x86/resctrl: Parse ACPI CMRC table Chen Yu
2026-10-14  3:00 ` [PATCH v9 09/12] x86/resctrl: Refactor the monitor read function Chen Yu
2026-10-14  3:00 ` [PATCH v9 10/12] fs/resctrl: Do not invoke smp_processor_id() in preemptible context Chen Yu
2026-10-14  3:00 ` [PATCH v9 11/12] x86/resctrl: Introduce erdt_cpu_has() and erdt_support() Chen Yu
2026-10-14  3:01 ` [PATCH v9 12/12] x86/resctrl: Add MMIO-based LLC occupancy monitoring support Chen Yu
2026-10-24  0:08   ` Reinette Chatre
2026-10-27 11:22     ` Chen Yu
2026-10-27 16:21       ` Reinette Chatre
2026-10-28  2:59         ` Chen Yu
2026-10-19 12:45 ` [PATCH v9 00/12] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu

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=auBdSeJUJqKx6MGu@chenyu-dev \
    --to=yu.c.chen@intel.com \
    --cc=anil.s.keshavamurthy@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=reinette.chatre@intel.com \
    --cc=tglx@kernel.org \
    --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 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.