Re: [PATCH v5 RESEND 7/7] fs/resctrl: Add info/moveable_mon_group

[Ben Horgan <ben.horgan@arm.com>]

Hi Jinjie, Reinette,

On 12/11/2026 01:42, Jinjie Ruan wrote:
> 
> 
> 在 2026/11/12 2:34, Reinette Chatre 写道:
>> Hi Jinjie and Ben,
> 
> Hi Reinette,
> 
>>
>> On 11/10/26 5:39 AM, Jinjie Ruan wrote:
>>> Moving a MON group into the mon_groups directory of another CTRL_MON
>>> group changes the CLOSID of the group while its RMID stays the same.
>>> Where the RMID is only meaningful together with the CLOSID, as on arm64
>>> MPAM, the move changes the RMID index of the group and is rejected with
>>> -EOPNOTSUPP.
>>>
>>> Userspace cannot tell whether the move is supported without trying it.
>>> Add "info/moveable_mon_group", which reads 1 when a MON group can be
>>> moved to another CTRL_MON group and 0 when the move is rejected, and
>>> refer to it where resctrl.rst describes the move.
>>>
>>> Suggested-by: Ben Horgan <ben.horgan@arm.com>
>>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>>
>> Do you find that this binary "supported/unsupported" accurately captures
> 
> I think this behavior is deterministic on MPAMv1, so that's enough for mpam.
> 
>> everything that MPAM may ever want to do in this area? Could it be that, for
> 
> That would be what the new version of MPAM does (such as v2 mentioned
> below), the behavior of the mapmv1 version is already determined..
> 
>> example, one day MPAM may be asked to support the move of a monitor group to
>> support scenarios where the reset of monitor counts is acceptable to the customer
>> and availability of PMG will be managed as part of the scenario needing support?

For such a destructive move I would have thought it would be better to
forbid the move and just rely on the user deleting the existing monitor
group and creating a new one at the new location. If we consider only
llc_occupancy on MPAM, which isn't affected by any requirement to be
free running as effectively the hardware re-measures the cache occupancy
on each read, then allowing monitor groups to be moved still gives a
misleading impression to the users. The actual cache occupancy of the
tasks in the moved monitor group stays the same but only the cache lines
allocated after the move with the new (PARTID, PMG) association are
accounted for in llc_occupancy. The tasks still get cache hits for the
lines allocated previous to the monitor group move.

Having said that, one problem with relying on deleting and creating a
new monitor group is that you have to keep track of the associated tasks
which isn't necessarily straight forward, e.g. when a child task is
started after deleting the monitor group.

Any relaxation of expectations of what happens when a monitor group is
moved would need explicit buy-in from the user as otherwise they could
rightly expect the established resctrl behaviour.

I haven't understood the reason why groups that monitor cpus can't be
moved. Is this impossible to implement even on an x86 system? Why can't
the cpus move move between control groups in the way that tasks do?

> 
> As stated in the MPAM manual, MPAMv2 completely separates PARTID and
> PMG, allowing for more flexible and fine-grained monitoring statistics

Which MPAM manual in particular are you referring to? Whilst the
separation of PARTID and PMG is definitely possible in MPAMv2 there is a
lot of nuance in this area.

> across partitions, so the CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID will not
> set for v2, However, it might need to be changed to a dynamic switch..
> 
>>
>> When adding a new interface it helps to consider future possible changes and
>> aim to create an interface that solves the immediate problem while leaving room
>> for future enhancements. If we do not do that the interface becomes a maze due
>> to new files just being added to address the problem of the day.
>>
> 
> I agree with your idea. We need to think twice before we act.
> 
>> I would like to propose that this patch be submitted separately with the goal
>> to obtain more feedback on the new interface. 
> 
> I don't object, but I understand this is the same thing as the previous
> patch. I'd like to hear Ben's advice.

Given that the documentation dependency has been avoided in your patch 6
I think as Reinette suggests it is indeed better to take some more time.
This is a proposal for new abi, after all.

Thanks,

Ben
> 
>>
>> Reinette
>