Re: [RFC PATCH] arm_mpam: resctrl: Separate MPAM domains

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Ben,

On 9/10/26 9:28 AM, Ben Horgan wrote:
> Hi Reinette,
> 
> On 10/09/2026 16:37, Reinette Chatre wrote:
>> Hi Ben,
>>
>> On 9/10/26 4:11 AM, Ben Horgan wrote:
>>> On 08/09/2026 22:12, Reinette Chatre wrote:
>>>> On 9/7/26 10:01 AM, Ben Horgan wrote:
>>>>> On 03/09/2026 16:29, Reinette Chatre wrote:
>>>>>> On 9/2/26 9:10 AM, Ben Horgan wrote:
>>>>>>> On 01/09/2026 00:54, Reinette Chatre wrote:
>>
>> ...
>>
>>>>>> It is not clear to me if a mon_comp of NULL is able to handle all scenarios since it looks
>>>>>> like mpam_resctrl_get_mon_domain_from_cpu() and mpam_resctrl_online_domain_hdr() does not
>>>>>> consider the component at all. Would that not cause monitoring features to depend on which
>>>>>> CPU of a domain comes online first?
>>>>>>
>>>>>> Could mon_comp perhaps be required to be !NULL here as a replacement for the earlier
>>>>>> "ctrl_comp" check to ensure there is a component with the CPU in its affinity mask?
>>>>>
>>>>> Doesn't the !any_mon_comp check provide this?
>>>>
>>>> This is the part that I do not understand since any_mon_comp seems to support the scenario
>>>> where a mon_comp may be NULL which is a scenario that I do not think resctrl can support.
>>>
>>> Ah, I see what you are getting at. As the monitor components are only considered when there topology
>>> matches the l3 cache (same cpu affinity for each instance) then the find_component() call will never
>>> fail and so mon_comp can't be NULL at this point.
>>>
>>>>
>>>> At a high level there seems to be three affinity masks used by the monitoring code:
>>>> the CPU affinity of the component belonging to the control resource class, the CPU affinity
>>>> of each component supporting each monitoring event, while these are three separate masks with
>>>> code sometimes treating them as though they can be different they are actually required to be the same?
>>>
>>> Monitor component CPU affinity is enforced by topology_matches_l3() to be the same as the L3.
>>> Additionally, traffic_matches_l3() adds extra conditions that mean that there can be considered an
>>> uninterrupted link between l3 and memory and so an MSC at either end is effectively the same. Namely
>>> the same restrictions I've mentioned before, only a single l3 cache, a single NUMA node and no
>>> intermediate caches.
>>>
>>> You list two rather than three here? Possibly you are also thinking the MSC cpu affinity which can
>>
>> I did mention three masks. Thank you for clarifying how the one mask (the "ctrl_comp" one) is associated with
>> either that of the control class or the same as the class associated with the first event. 
> 
> Ah yes, I misunderstood.
> 
>>
>> Regarding the other two masks: it seems to me as though the CPU masks associated with the two supported events
>> are managed separately. This means that theoretically the class associated with QOS_L3_OCCUP_EVENT_ID could have
>> components with different affinity from the components of the class associated with QOS_L3_MBM_TOTAL_EVENT_ID. A CPU
>> being onlined could thus be associated with QOS_L3_OCCUP_EVENT_ID (resulting in mon_comp being
>> initialized for this CPU) but not with QOS_L3_MBM_TOTAL_EVENT_ID (mon_comp is NULL for the same CPU). In
>> this scenario, "any_mon_comp" will be true and the domain created and onlined while it does not
>> actually support both events?
> 
> Hmm, it depends what you mean by "theoretically". In mpam_resctrl_pick_counters() the class to back
> each event is chosen. For QOS_L3_OCCUP_EVENT_ID it will always be the class at the L3. For
> QOS_L3_MBM_TOTAL_EVENT_ID the topology_matches_l3() call will check the cpu mask matches the L3.
> Does that answer query or am I missing something else?
I mean "theoretically" because it seems that the CPU online code (specifically domain creation) supports
the scenario where these CPU masks of the two events are different (mon_comp can be set for one event but
not the other) while the rest of the driver seems to make an effort to keep these CPU masks identical (as
you highlight) and there is not actually support for them being different.

The planned changes discussed here are for the domain creation and will touch the code handling this
scenario. I was hoping to just change the data structures while maintaining the current flows as closely
as possible. I currently struggle with maintaining this flow that can never, and more importantly should
never, be encountered.

Do (admittedly crude) guardrails like below capture the existing driver requirements?

diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 9d223057953a..dbd06371890c 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -1681,11 +1681,18 @@ mpam_resctrl_alloc_domain(unsigned int cpu, struct mpam_resctrl_res *res)
 				continue;       // dummy resource
 
 			mon_comp = find_component(mon->class, cpu);
+			if (!mon_comp) {
+				WARN_ON_ONCE(0);
+				err = -EFAULT;
+				goto offline_ctrl_domain;
+			}
 			dom->mon_comp[eventid] = mon_comp;
-			if (mon_comp)
-				any_mon_comp = mon_comp;
+			any_mon_comp = mon_comp;
 		}
-		if (!any_mon_comp) {
+
+		/* hack */
+		if (!cpumask_equal(&dom->mon_comp[QOS_L3_OCCUP_EVENT_ID]->affinity,
+				   &dom->mon_comp[QOS_L3_MBM_TOTAL_EVENT_ID]->affinity)) {
 			WARN_ON_ONCE(0);
 			err = -EFAULT;
 			goto offline_ctrl_domain;


Reinette