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

["Chen, Yu C" <yu.c.chen@intel.com>]

Hi Reinette,

On 6/25/2026 7:44 AM, Reinette Chatre wrote:
> Hi Chenyu,
> On 6/23/26 9:05 PM, Chen, Yu C wrote:
>> 1. At ACPI parse time , record the full CPU mask from CACD for each
>>     RMDD domain without checking online state or resolving L3 cache IDs.
> 
> ack.
> 
>>     Store a per-CPU pointer (erdt_cpu_domain[cpu]) for O(1) lookup.
> 
> Why is such optimization needed? From what I can tell this pointer is
> only accessed *once*. I do not think onlining a CPU is a hot path?
> Could this be simplified to just be a list of ERDT domains?
> 

Yes, we could store it in a linked list for later use, provided we add a
pointer in rdt_hw_l3_mon_domain to reference it.

>> 2. At CPU online time (resctrl_arch_online_cpu), validate that the CPU's
>>     CPUID-derived L3 ID is consistent with other CPUs in the same RMDD:
>>     - First online CPU in an RMDD establishes the L3 ID for that domain
>>       and inserts the domain into erdt_domain_xa keyed by L3 cache ID.
>>     - Subsequent CPUs must match. On mismatch, the CPU is refused from resctrl.
> 
> Considering that this now establishes 1:1 between RMDD and resctrl domain and that
> resctrl already maintains a list of domains, could the x86 arch specific monitoring
> domain (struct rdt_hw_l3_mon_domain) perhaps just point to the ERDT monitoring data
> for that domain instead of maintaining a separate array of domains? So, when x86 is
> requested to read monitoring data for a domain there would be no need to query an
> array for the ERDT domain info since the containing structure already has a pointer
> to it.
> 
> This may need more care to organize the ERDT per-domain monitoring data structure when
> considering the references to upcoming additions that are not clear to me at this time.
> 

I see. We could add a void *priv pointer to struct rdt_hw_l3_mon_domain.
During l3_mon_domain_setup(), we can assign this pointer to the 
corresponding
erdt_domain_info object from the previously created list.
Since each rdt_hw_l3_mon_domain instance is freed when the last CPU in 
its domain
goes offline, we need to keep the global list of struct erdt_domain_info 
objects
persistent at all times. Going forward, we may also need to add the same 
pointer
assignment to rdt_hw_ctrl_domain for the upcoming region-aware MBA changes.

>>
>> 3. erdt_mon_read() looks up erdt_domain_xa by hdr->id (L3 cache ID) as before,
>>     but the xarray is now populated lazily at CPU online time.
> 
> 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?
> 

If we add the struct erdt_domain_info pointer to rdt_hw_l3_mon_domain, then
there is no need to maintain the xarray.

thanks,
Chenyu