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

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

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. 

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?

...
>> 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