Re: [PATCH v4 1/6] x86/resctrl: Parse ACPI ERDT table and map RMDD domains by L3 cache ID

[Chen, Yu C]

Hi Reinette,

On 6/25/2026 8:24 AM, Reinette Chatre wrote:
> 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?

If erdt_domain_info is embedded within rdt_hw_l3_mon_domain, an xarray 
might be not mandatory
- any data structure form works; we only need to store the data in 
erdt.c for later
lookup in the CPU online handler.

If erdt_domain_info is maintained separately as in current version, we 
need to create
mappings from L3 IDs to erdt_domain_info inside erdt_mon_read(). The 
xarray serves
as a fast lookup mechanism when sparse arrays are not used(waste memory).

thanks,
Chenyu