mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>, "Chen, Yu C" <yu.c.chen@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tglx@kernel.org" <tglx@kernel.org>,
	"bp@alien8.de" <bp@alien8.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"dave.martin@arm.com" <dave.martin@arm.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"fenghuay@nvidia.com" <fenghuay@nvidia.com>,
	"babu.moger@amd.com" <babu.moger@amd.com>,
	"Keshavamurthy, Anil" <anil.keshavamurthy@broadcom.com>,
	"chen.yu@linux.dev" <chen.yu@linux.dev>
Subject: Re: [PATCH v4 1/6] x86/resctrl: Parse ACPI ERDT table and map RMDD domains by L3 cache ID
Date: Wed, 24 Jun 2026 17:24:03 -0700	[thread overview]
Message-ID: <2152d065-c978-4ac3-a75c-358a763a4394@intel.com> (raw)
In-Reply-To: <SJ1PR11MB60837755496AC1AB6DFC11DFFCED2@SJ1PR11MB6083.namprd11.prod.outlook.com>

Hi Tony,

On 6/24/26 4:58 PM, Luck, Tony wrote:
>> I do not see the need for an xarray. As new domains are created during CPU online their
>> initialization can just point to the needed data, no?
> 
> Reinette,
> 
> Historical note. The xarray was added during early development on a simulator where the L3
> domain numbers were wildly sparse. That turned out to be an artifact of the simulator
> CPUID and BIOS interactions. On real h/w the L3 domains show up as 0, 1, 2, 3, ... 

resctrl dynamically allocates monitoring domains as the CPUs come online and the monitoring
domains are assigned the domain ID discovered from the system. This should not be impacted by
sparse domain numbers and works without an xarray, no? What am I missing?

> But the xarray does still serve some purpose. Without it you’d need two passes through the
> ACPI ERDT structure. One to count how many RMDD substructures are present to allocate
> space, then second pass to parse things.
The data structures containing the domain data discovered from ERDT could just be dynamically
allocated with a single pass as the domains are discovered, similar to how rdt_resource::mon_domains
is populated, no? The difference is that the "ERDT domains" are discovered during initialization.

I do not see a need for a separate xarray indexed by domain ID during "runtime" since we already
have the architecture specific domain structures. struct rdt_l3_mon_domain could just point to
its associated ERDT domain when it (struct rdt_l3_mon_domain) is initialized, no?

You could use an xarray during initial RMDD parsing but from what I understand its index
is of no use since it was established early in this discussion that RMDD domain ID cannot be
assumed to be the same as enumerated via CPUID leaf 0x4. So even if you use an xarray the
CPU online handler needs to iterate over the xarray instead of indexing directly into it
to find CPU being onlined and through that determine the "RMDD domain ID" associated with the
CPUID leaf 0x4 cache ID of CPU being onlined. What is the benefit of an xarray when never
indexing into it?

Reinette

  reply	other threads:[~2026-06-25  0:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-13  7:56 [PATCH v4 0/6] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
2026-06-13  7:56 ` [PATCH v4 1/6] x86/resctrl: Parse ACPI ERDT table and map RMDD domains by L3 cache ID Chen Yu
2026-06-18 23:37   ` Reinette Chatre
2026-06-22  9:07     ` Chen, Yu C
2026-06-22 21:28       ` Reinette Chatre
2026-06-23  6:29         ` Chen, Yu C
2026-06-23 11:43           ` Chen, Yu C
2026-06-23 16:46             ` Reinette Chatre
2026-06-24  4:05               ` Chen, Yu C
2026-06-24  6:04                 ` Chen, Yu C
2026-06-24 23:44                   ` Reinette Chatre
2026-06-24 23:58                     ` Luck, Tony
2026-06-25  0:24                       ` Reinette Chatre [this message]
2026-06-25 14:59                         ` Chen, Yu C
2026-06-25 14:33                     ` Chen, Yu C
2026-06-25 15:54                       ` Reinette Chatre
2026-06-13  7:57 ` [PATCH v4 2/6] x86/resctrl: Parse ACPI CMRC table Chen Yu
2026-06-13  7:57 ` [PATCH v4 3/6] x86/resctrl: Rename prev_msr to prev_mon_val Chen Yu
2026-06-18 23:39   ` Reinette Chatre
2026-06-22 12:42     ` Chen, Yu C
2026-06-22 21:29       ` Reinette Chatre
2026-06-23  7:48         ` Chen, Yu C
2026-06-23 16:47           ` Reinette Chatre
2026-06-24  6:16             ` Chen, Yu C
2026-06-13  7:57 ` [PATCH v4 4/6] x86/resctrl: Refactor the monitor read function Chen Yu
2026-06-13  7:57 ` [PATCH v4 5/6] fs/resctrl: Do not invoke smp_processor_id() in preemptible context Chen Yu
2026-06-13  7:57 ` [PATCH v4 6/6] x86/resctrl: Add support for L3 occupancy monitoring via RMID MMIO read Chen Yu
2026-06-18 23:40   ` Reinette Chatre
2026-06-22 14:09     ` Chen, Yu C
2026-06-22 21:30       ` Reinette Chatre
2026-06-23  5:00         ` Chen, Yu C
2026-06-23 16:48           ` Reinette Chatre
2026-06-24  9:00             ` Chen, Yu C
2026-06-24 23:44               ` 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=2152d065-c978-4ac3-a75c-358a763a4394@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=dave.martin@arm.com \
    --cc=fenghuay@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.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