Re: [PATCH v9 0/9] arm_mpam: Introduce Narrow-PARTID feature

[Jinjie Ruan <ruanjinjie@huawei.com>]

在 2026/10/22 8:02, Shaopeng Tan (Fujitsu) 写道:
> Hello Jinjie,
> 
> I would like to confirm the following points.
> 
>  - Is the number of reqPARTIDs per intPARTID dependent on the total number of intPARTIDs and reqPARTIDs?

Hi Shaopeng,

You are right,

reqPARTID % mpam_num_closid(the total number of intPARTIDs) -> intPARTID

so reqPARTIDs per intPARTID = Total number of reqPARTIDs / Total number
of intPARTIDs

>  - Given that requirements for the number of control and monitoring groups vary by user, 
>    would dynamic configuration of the mapping ratio between intPARTID and reqPARTID be a more suitable approach?

No, in v8 James has suggested "static first" and avoid exposing user ABI
in multiple places below:

"I think we should leave anything dynamic here for the further future,
 lets get static partitioning working first"

"I'd prefer we get the static grouping working first, before we work out
what needs changing in resctrl to do it dynamically"

"I'd like to avoid exposing user ABI to control this until we get it
working, then we can talk about whether to try making the grouping
dynamically managed by resctrl."

Link:
https://lore.kernel.org/all/2944b506-a462-42f8-95cf-404241fb27f0@arm.com/
Link:
https://lore.kernel.org/all/ec8bc617-9e74-4749-ab33-39d1079415cc@arm.com/


>  - Regarding the mapping logic, some reqPARTIDs may remain unused. Is this the expected behavior?

As mentioned above, we are implementing the static solution first, so it
is expected behavior that some of the reqpartids are not used.

>  - Considering that Arm has previously implemented this,
>    are there any gaps between their implementation and Huawei’s requirements?
>    https://lore.kernel.org/linux-arm-kernel/20241212154000.330467-1-Dave.Martin@arm.com/

I haven't looked at the ARM implementation yet (I'll refer to it later),
but currently the code is being gradually aligned with the maintainer's
review comments.

> 
> Best regards,
> Shaopeng TAN
> 
> 
>> Background
>> ==========
>>
>> In ARM MPAM, a monitoring group is defined by a (PARTID, PMG) pair.
>> However, many production platforms implement only a single PMG bit,
>> limiting the total number of monitoring groups long before the request
>> PARTID space is exhausted.
>>
>> Hardware Mechanism
>> ===================
>>
>> Platforms with "PARTID narrowing" mitigate this by mapping multiple
>> request PARTIDs onto a single internal PARTID. The internal PARTID
>> dictates the control group configuration, while each individual request
>> PARTID functions as an independent monitoring group. This decouples
>> control and monitoring allocation, allowing more monitoring groups
>> than the PMG constraint normally permits.
>>
>> Software Strategy
>> ==================
>>
>> Using request PARTIDs beyond the internal range is only safe when no MPAM
>> class loses a non-aliasing control. While aliasing controls (e.g., cache
>> portion bitmaps) can be safely replicated across request PARTIDs,
>> non-aliasing controls (e.g., cache capacity) are additive and cannot.
>>
>> To ensure safety, this series implements a completely static grouping
>> policy evaluated once before resctrl_init(). If any class contains
>> non-aliasing controls without narrowing capabilities, the expansion
>> is bypassed. This infrastructure remains completely transparent
>> to user-space.
>>
>> Patch Architecture
>> ====================
>>
>> - Patches 1-4: Bugfix and preparatory rework.
>>
>> - Patch 5: Track both internal and request PARTID limits per class.
>>
>> - Patches 6-7: Implement driver-side modulo interleaving for request
>>   PARTIDs and flat global RMID indexing.
>>
>> - Patches 8-9: Identify non-aliasing controls, and enable the narrowing
>>   expansion by lifting driver-side partid_max clamping and freeing
>>   the extra request PARTIDs for resctrl.
>>
>> Changes since v8
>> - Replaced dynamic allocation with pure static grouping as requested by James.
>> - Removed the 'mpam.intpartid_max' boot parameter; expansion is now automatic.
>> - Extended safety verification to all classes, preserving
>>   forward-compatibility for unknown classes that might gain resctrl
>>   schemas later.
>> - Decoupled the driver infrastructure patch from the resctrl glue patch.
>> - Introduced resctrl_arch_rmid_idx_match() to clean up the RMID allocator.
>> - Link to v8: https://lore.kernel.org/all/20260413085405.1166412-1-zengheng4@huawei.com/
>>
>> Previous Versions
>> =================
>>
>>     v7: https://lore.kernel.org/all/20260317132141.1272506-1-zengheng4@huawei.com/
>>     v6: https://lore.kernel.org/all/20250222112448.2438586-1-zengheng4@huawei.com/
>>     v5: https://lore.kernel.org/all/20250217031852.2014939-1-zengheng4@huawei.com/
>> RFC-v4: https://lore.kernel.org/all/20250104101224.873926-1-zengheng4@huawei.com/
>> RFC-v3: https://lore.kernel.org/all/20241207092136.2488426-1-zengheng4@huawei.com/
>> RFC-v2: https://lore.kernel.org/all/20241119135104.595630-1-zengheng4@huawei.com/
>> RFC-v1: https://lore.kernel.org/all/20241114135037.918470-1-zengheng4@huawei.com/
>>
>> Jinjie Ruan (6):
>>   fs/resctrl: Add resctrl_arch_rmid_idx_match() helper
>>   arm_mpam: resctrl: Add resctrl_closid_rmid_to_partid_pmg() helper
>>   arm_mpam: Add a helper to check a PARTID is in a CLOSID
>>   arm_mpam: Track the PARTID and internal PARTID limits per class
>>   arm_mpam: Identify the non-aliasing controls
>>   arm_mpam: Use the request PARTIDs beyond the internal range
>>
>> Zeng Heng (3):
>>   fs/resctrl: Unmount resctrl with the CDP state it was mounted with
>>   arm_mpam: Divide the PARTIDs between the control groups
>>   arm_mpam: Map resctrl RMIDs onto the request PARTIDs
>>
>>  arch/x86/include/asm/resctrl.h  |   6 +
>>  drivers/resctrl/mpam_devices.c  | 105 +++++++++++++---
>>  drivers/resctrl/mpam_internal.h |  24 ++++
>>  drivers/resctrl/mpam_resctrl.c  | 213 +++++++++++++++++++++++++++-----
>>  fs/resctrl/monitor.c            |  13 +-
>>  fs/resctrl/rdtgroup.c           |  38 +++++-
>>  include/linux/arm_mpam.h        |   1 +
>>  7 files changed, 341 insertions(+), 59 deletions(-)
>>
>> -- 
>> 2.34.1
>>

-- 
Best regards,
Jinjie