From: Reinette Chatre <reinette.chatre@intel.com>
To: "Chen, Yu C" <yu.c.chen@intel.com>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
<tglx@kernel.org>, <bp@alien8.de>, <mingo@redhat.com>,
<dave.hansen@linux.intel.com>, <hpa@zytor.com>,
<fenghuay@nvidia.com>, <babu.moger@amd.com>,
<anil.keshavamurthy@broadcom.com>, <chen.yu@linux.dev>,
Hongyu Ning <hongyu.ning@linux.intel.com>, <tony.luck@intel.com>
Subject: Re: [PATCH v5 03/10] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask for RMDD domains
Date: Tue, 14 Jul 2026 09:13:07 -0700 [thread overview]
Message-ID: <0814ad58-8c3e-4e81-aadf-026c0b52f775@intel.com> (raw)
In-Reply-To: <113d3788-4388-4bf0-ad1f-d03232d770b6@intel.com>
Hi Chenyu,
On 7/14/26 8:19 AM, Chen, Yu C wrote:
> Hi Chenyu,
>
> On 7/11/2026 7:42 AM, Reinette Chatre wrote:
>> Hi Chenyu,
>>
>> On 7/1/26 6:45 AM, Chen Yu wrote:
>>> From: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
>>>
>>> Parse the ERDT (Enhanced RDT) ACPI table so enhanced RDT features can
>>> consume firmware-provided domain information.
>>>
>>> The ERDT may contain these sub-tables:
>>>
>>> - Resource Management Domain Description Structure (RMDD)
>>> - CPU Agent Collection Description Structure (CACD)
>>> - Cache Monitoring Registers for CPU Agents Description Structure
>>> (CMRC)
>>
>> How should "The ERDT may contain these sub-tables" be interpreted here?
>> This sounds like some high level partial description of ERDT that is
>> not specific to this patch.
>>
>
> I planned to add some background context on ERDT. Let me remove unrelated
> content and change the sentence to:
> Parse the RMDD subtables within the ERDT ACPI table and their nested
> CACD entries to construct per-domain CPU masks.
Thank you. Making this patch specific will also help to identify unrelated
changes, for example the introduction of ERDT_MMIO_CMRC_BASE that would be
more appropriate for the patch that uses it.
...
>>> +
>>> +#include <asm/apic.h>
>>> +
>>> +#include "internal.h"
>>> +
>>> +static LIST_HEAD(domain_info_list);
>>> +
>>> +static bool __erdt_enabled;
>>
>> Is double underscore needed?
>
> The double underscore was used to prevent name collisions with the
> existing erdt_enabled(). Let me switch it to a single underscore instead.
You say "existing" but I am not able to find erdt_enabled() in this series. Is it
something that will be needed later?
>
>> Could you please add a comment above the variable to describe what it means when
>> "erdt is enabled"?
>>
>
> OK, let me add this:
>
> /*
> * Set when the ERDT ACPI table has been successfully parsed and at least
> * one valid RMDD domain with a CACD cpumask exists. Cleared on teardown.
To make this easier to understand, please aim to have comments that do not describe
code verbatim but instead what it means. Consider, for example, something like:
"True when the ERDT ACPI table describes at least one domain with at least one CPU."
>>> + d = container_of(pos, struct erdt_domain_info, list);
>>> + list_del(pos);
>>> + cleanup_one_domain(d);
>>> + }
>>> + __erdt_enabled = false;
>>> + valid_subtbl_mask = 0;
>>> +}
>>> +
>>> +static __init int enumerate_erdt_table(struct acpi_table_header *table_hdr)
>>> +{
>>> + struct acpi_table_erdt *erdt = (struct acpi_table_erdt *)table_hdr;
>>> + struct acpi_subtbl_hdr_16 *subtbl;
>>> + void *table_end;
>>> +
>>> + if (erdt->header.revision != ERDT_VALID_VERSION) {
>>> + pr_info("Unsupported ERDT table revision %d\n", erdt->header.revision);
>>
>> Would it be helpful to print what the ERDT table revision is to help diagnostics?
>>
>
> Yes, it will print the revision, do you mean print the expected revision?
>
> pr_info("Unsupported ERDT table revision %d (expected %d)\n",
> erdt->header.revision, ERDT_VALID_VERSION);
oh, apologies, I misread what you had originally. Even so, your new proposal looks good
to me.
As a sidenote, please use most accurate conversion when printing, for example %u for
unsigned instead of %d.
Reinette
next prev parent reply other threads:[~2026-07-14 16:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-01 13:44 [PATCH v5 00/10] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
2026-07-01 13:45 ` [PATCH v5 01/10] x86/resctrl: Require 64-bit x86 for resctrl support Chen Yu
2026-07-01 13:45 ` [PATCH v5 02/10] x86/topology: Export topo_lookup_cpuid() for resctrl use Chen Yu
2026-07-10 23:35 ` Reinette Chatre
2026-07-14 15:45 ` Chen, Yu C
2026-07-01 13:45 ` [PATCH v5 03/10] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask for RMDD domains Chen Yu
2026-07-10 23:42 ` Reinette Chatre
2026-07-14 15:19 ` Chen, Yu C
2026-07-14 16:13 ` Reinette Chatre [this message]
2026-07-14 16:33 ` Chen, Yu C
2026-07-01 13:45 ` [PATCH v5 04/10] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online Chen Yu
2026-07-10 23:45 ` Reinette Chatre
2026-07-14 8:51 ` Chen, Yu C
2026-07-14 16:13 ` Reinette Chatre
2026-07-14 16:24 ` Chen, Yu C
2026-07-01 13:46 ` [PATCH v5 05/10] x86/resctrl: Parse ACPI CMRC table Chen Yu
2026-07-10 23:46 ` Reinette Chatre
2026-07-14 16:27 ` Chen, Yu C
2026-07-01 13:46 ` [PATCH v5 06/10] x86/resctrl: Replace "msr" in monitoring data identifiers Chen Yu
2026-07-10 23:47 ` Reinette Chatre
2026-07-01 13:46 ` [PATCH v5 07/10] x86/resctrl: Refactor the monitor read function Chen Yu
2026-07-01 13:47 ` [PATCH v5 08/10] fs/resctrl: Do not invoke smp_processor_id() in preemptible context Chen Yu
2026-07-10 23:48 ` Reinette Chatre
2026-07-01 13:47 ` [PATCH v5 09/10] x86/resctrl: Introduce helpers to read L3 occupancy via MMIO Chen Yu
2026-07-10 23:53 ` Reinette Chatre
2026-07-01 13:47 ` [PATCH v5 10/10] x86/resctrl: Enable " Chen Yu
2026-07-10 23: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=0814ad58-8c3e-4e81-aadf-026c0b52f775@intel.com \
--to=reinette.chatre@intel.com \
--cc=anil.keshavamurthy@broadcom.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@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