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

[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?
 - 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?
 - Regarding the mapping logic, some reqPARTIDs may remain unused. Is this the expected behavior?
 - 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@xxxxxxx/

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@xxxxxxxxxx/
> 
> Previous Versions
> =================
> 
>     v7: https://lore.kernel.org/all/20260317132141.1272506-1-zengheng4@xxxxxxxxxx/
>     v6: https://lore.kernel.org/all/20250222112448.2438586-1-zengheng4@xxxxxxxxxx/
>     v5: https://lore.kernel.org/all/20250217031852.2014939-1-zengheng4@xxxxxxxxxx/
> RFC-v4: https://lore.kernel.org/all/20250104101224.873926-1-zengheng4@xxxxxxxxxx/
> RFC-v3: https://lore.kernel.org/all/20241207092136.2488426-1-zengheng4@xxxxxxxxxx/
> RFC-v2: https://lore.kernel.org/all/20241119135104.595630-1-zengheng4@xxxxxxxxxx/
> RFC-v1: https://lore.kernel.org/all/20241114135037.918470-1-zengheng4@xxxxxxxxxx/
> 
> 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
>