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

[Ben Horgan]

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?

Thanks,

Ben

> 
> ...
>>> I think that it will support the multiple control work if this is done upstream first.
>>> I will incorporate your changes in the next version ... I believe that would make you
>>> a co-author?
>>
>> I don't think co-author is necessary as I've just offered review and you mentioned you'd already
>> tried out the new structures. Up to you though.
> Let's see how the next version goes as I become more familiar with MPAM.
> 
> Thank you very much for all the insights.
> 
> Reinette
>