On MPAM systems, monitoring groups are identified in the hardware by a
(PARTID, PMG) pair.  Two monitoring group identifiers are the same only
if the PARTIDs and PMGs both match.  This means that the number of
monitoring groups that can be created in each control group is the same
as the number of distinct PMG values supported by the hardware.  The
number of monitoring groups that exist in other control groups at the
same time makes no difference to this.

Currently, the MPAM driver takes the cautious approach and always
num_rmids = 1.

Relax this limit, by advertising the number of distinct PMG values
supported by the hardware.

Code/Data Prioritization (CDP) makes no difference, since although this
doubles the number of (PARTID, PMG) pairs available to a control group,
each monitoring group now consumes two pairs instead of one.

Suggested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---

This patch is based on:

git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/snapshot/v6.16-rc5

 drivers/platform/arm64/mpam/mpam_resctrl.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/arm64/mpam/mpam_resctrl.c b/drivers/platform/arm64/mpam/mpam_resctrl.c
index f1e565cd1aac..f4f6fa9acfff 100644
--- a/drivers/platform/arm64/mpam/mpam_resctrl.c
+++ b/drivers/platform/arm64/mpam/mpam_resctrl.c
@@ -1208,12 +1208,17 @@ static void mpam_resctrl_monitor_init(struct mpam_class *class,
 		/*
 		 * Unfortunately, num_rmid doesn't mean anything for
 		 * mpam, and its exposed to user-space!
-		 * num-rmid is supposed to mean the number of groups
-		 * that can be created, both control or monitor groups.
-		 * For mpam, each control group has its own pmg/rmid
-		 * space.
+		 *
+		 * num-rmid is supposed to mean the minimum number of
+		 * monitoring groups that can exist simultaneously, including
+		 * the default monitoring group for each control group.
+		 *
+		 * For mpam, each control group has its own pmg/rmid space, so
+		 * it is not appropriate to advertise the whole rmid_idx space
+		 * here.  But the pmgs corresponding to the parent control
+		 * group can be allocated freely:
 		 */
-		l3->num_rmid = 1;
+		l3->num_rmid = mpam_pmg_max + 1;
 
 		switch (type) {
 		case QOS_L3_MBM_LOCAL_EVENT_ID:

base-commit: b8e4905233fe45814b3c73be7e091f172cfb86ce
-- 
2.34.1

Hi Dave,

On 20/08/2025 14:15, Dave Martin wrote:
> On MPAM systems, monitoring groups are identified in the hardware by a
> (PARTID, PMG) pair.  Two monitoring group identifiers are the same only
> if the PARTIDs and PMGs both match.  This means that the number of
> monitoring groups that can be created in each control group is the same
> as the number of distinct PMG values supported by the hardware.  The
> number of monitoring groups that exist in other control groups at the
> same time makes no difference to this.
> 
> Currently, the MPAM driver takes the cautious approach and always
> num_rmids = 1.
> 
> Relax this limit, by advertising the number of distinct PMG values
> supported by the hardware.
> 
> Code/Data Prioritization (CDP) makes no difference, since although this
> doubles the number of (PARTID, PMG) pairs available to a control group,
> each monitoring group now consumes two pairs instead of one.

Thanks, I've picked this up. It may get squashed into the patch that adds these lines
before going upstream...


Thanks,

James

Hi James,

On Wed, Aug 27, 2025 at 06:16:00PM +0100, James Morse wrote:
> Hi Dave,
> 
> On 20/08/2025 14:15, Dave Martin wrote:
> > On MPAM systems, monitoring groups are identified in the hardware by a
> > (PARTID, PMG) pair.  Two monitoring group identifiers are the same only
> > if the PARTIDs and PMGs both match.  This means that the number of
> > monitoring groups that can be created in each control group is the same
> > as the number of distinct PMG values supported by the hardware.  The
> > number of monitoring groups that exist in other control groups at the
> > same time makes no difference to this.
> > 
> > Currently, the MPAM driver takes the cautious approach and always
> > num_rmids = 1.
> > 
> > Relax this limit, by advertising the number of distinct PMG values
> > supported by the hardware.
> > 
> > Code/Data Prioritization (CDP) makes no difference, since although this
> > doubles the number of (PARTID, PMG) pairs available to a control group,
> > each monitoring group now consumes two pairs instead of one.
> 
> Thanks, I've picked this up. It may get squashed into the patch that adds these lines
> before going upstream...
> 
> 
> Thanks,
> 
> James

Thanks for picking this up.

Will that be in the next snapshot?

Cheers
---Dave
>