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

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 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?

As stated in the MPAM manual, MPAMv2 completely separates PARTID and
PMG, allowing for more flexible and fine-grained monitoring statistics
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.

> 
> Reinette

-- 
Best regards,
Jinjie