Re: [RFC PATCH v2 00/10] arm_mpam: resctrl: Separate MPAM domains

[Reinette Chatre]

Hi Ben,

On 10/22/26 3:45 AM, Ben Horgan wrote:
> On 19/10/2026 23:07, Reinette Chatre wrote:
>> RFC v1: https://lore.kernel.org/lkml/85ca29e89eacf12cfa7071249419e7cadb8f0691.1788220029.git.reinette.chatre@xxxxxxxxx/
>>
>> The MPAM driver represents a resctrl domain with a single structure,
>> struct mpam_resctrl_dom, that holds both a control domain and a
>> monitoring domain. On a system that supports both allocation and
>> monitoring, one instance is created for each domain and its two
>> domains are added to the resource's control and monitoring domain
>> lists.
>>
>> Holding both domains in one structure requires control and monitoring
>> to be done at the same scope, and ties each control domain to a
>> monitoring domain. This does not fit the proposed support for multiple
>> controls per resource [1]. There, each control of a resource, for
>> example a "min" and a "max" memory bandwidth control, has its own list
>> of control domains while the resource keeps a single list of
>> monitoring domains. With one structure for both, every control domain
>> would come with a monitoring domain of its own, which does not reflect
>> the resource.
>>
>> This series gives control and monitoring domains their own structures,
>> set up and torn down independently as CPUs come online and go offline,
>> in preparation for supporting multiple controls per resource. Along
>> the way it stops failing CPU online when a domain cannot be set up,
>> and adds checks when setting up a monitoring domain.
>>
>>   1-2   Preparatory cleanups of domain allocation
>>   3     Do not fail CPU online when domain setup fails
>>   4-6   Separate the control and monitoring domain structures
>>   7-9   Checks when setting up a monitoring domain
>>   10    Comment update, kept separate for review
>>
>> An earlier version of the domain split was posted on its own [2]. This
>> version incorporates the feedback from that discussion. It gives each
>> type of domain its own structure instead of duplicating the shared
>> one, sets up each domain independently instead of undoing one domain
>> when setting up the other fails, and adds the checks in patches 8 and
>> 9.
>>
>> Patch 7 turns a WARN_ON_ONCE(0) into a warning that fires. It is a
>> separate patch because it is not clear whether the silent failure was
>> intended. If it was, the patch can instead drop the dead
>> WARN_ON_ONCE().
>>
>> This is an RFC because I am only able to compile test MPAM changes,
>> which is also why the patches are small and each change is justified
>> on its own. Patches can be squashed if preferred, for example patch 10
>> into patches 5 and 9. Testing on MPAM hardware would be greatly
>> appreciated, as is any other feedback.
> 
> On an initial look through the patches everything seems sensible and in line with what we discussed
> previously. I've given it a quick sanity check on a couple of models and nothing goes wrong. Is
> there any particular shape of system needed to exercise corner cases? I'll try with monitor only
> systems and control only systems and do some more testing on real hardware as well.

Thank you very much for considering this series. This is foundational to the support for
multiple controls.

MPAM supports a variety of system shapes and this code made changes to most of
the flows dealing with this variety. Any testing is appreciated. If possible, some
scenarios that I find interesting:
- Even though you already mentioned monitor only system I would like to highlight that
  this is a shape of particular interest since this series no longer checks the res->class
  borrowed from the monitoring class and just relies on the monitoring classes themselves
  as we discussed during RFCv1.
- System where monitoring is from different class than the controls.
- System with L2 and L3 controls.

Shapes where multiple domains are possible are more interesting. If such testing is possible
it would be great if _entire_ domain can be torn down and recreated with and without resctrl
mounted (while keeping an eye on schemata file, mon_data contents, and info/ directories),
ideally with as many as possible "Kernel Hacking" configuration options enabled.
 
> Thank you very much for taking so much care over the MPAM side of things.

You are welcome. I aimed to make the changes as small as possible but I understand
this is disruptive to the MPAM design. After this lands, the remaining changes
needed to support multiple controls look to be mostly mechanical.

Thank you very much for taking a look and all the testing you are doing.

Reinette