arch/x86/include/asm/resctrl.h | 7 + drivers/resctrl/mpam_devices.c | 83 ++++++--- drivers/resctrl/mpam_internal.h | 7 +- drivers/resctrl/mpam_resctrl.c | 289 ++++++++++++++++++++++++++++---- fs/resctrl/monitor.c | 50 +++++- fs/resctrl/rdtgroup.c | 24 ++- include/linux/arm_mpam.h | 17 ++ include/linux/resctrl.h | 21 +++ 8 files changed, 434 insertions(+), 64 deletions(-)
This series applies on top of the mpam_resctrl_glue_v5_debugfs branch of:
https://gitlab.arm.com/linux-arm/linux-bh.git
Background
==========
On x86, the resctrl allows creating up to num_rmids monitoring groups
under parent control group. However, ARM64 MPAM is currently limited by
the PMG (Performance Monitoring Group) count, which is typically much
smaller than the theoretical RMID limit. This creates a significant
scalability gap: users expecting fine-grained per-process or per-thread
monitoring quickly exhaust the PMG space, even when plenty of reqPARTIDs
remain available.
The Narrow-PARTID feature, defined in the ARM MPAM architecture,
addresses this by associating reqPARTIDs with intPARTIDs through a
programmable many-to-one mapping. This allows the kernel to present more
logical monitoring contexts.
Design Overview
===============
The implementation extends the RMID encoding to carry reqPARTID
information:
RMID = reqPARTID * NUM_PMG + PMG
In this patchset, a monitoring group is uniquely identified by the
combination of reqPARTID and PMG. The closid is represented by intPARTID,
which is exactly the original PARTID.
For systems with homogeneous MSCs (all supporting Narrow-PARTID), the
driver exposes the full reqPARTID range directly. For heterogeneous
systems where some MSCs lack Narrow-PARTID support, the driver utilizes
PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring
capacity. The sole exception is when MBA MSCs lack Narrow-PARTID support,
their percentage-based control mechanism prevents the use of PARTIDs as
reqPARTIDs.
Capacity Improvements
=====================
--------------------------------------------------------------------------
The maximum | Sub-monitoring groups | System-wide
number of | under a control group | monitoring groups
--------------------------------------------------------------------------
Without | |
reqPARTID | PMG | intPARTID * PMG
--------------------------------------------------------------------------
reqPARTID | |
static allocation | (reqPARTID // intPARTID) * PMG | reqPARTID * PMG
--------------------------------------------------------------------------
reqPARTID | |
dynamic allocation | (reqPARTID − intPARTID + 1) * PMG | reqPARTID * PMG
--------------------------------------------------------------------------
Under MPAM, the number of reqPARTID is always greater than or equal to
intPARTID.
Series Structure
================
Patch 1: Fix pre-existing out-of-range PARTID issue between mount sessions.
Patches 2-5: Implement static reqPARTID allocation.
Patches 6-9: Implement dynamic reqPARTID allocation.
---
Compared with v2:
- Add dynamic reqPARTID allocation implementation.
- Add Patch 1 to fix pre-existing out-of-range PARTID issue.
- Drop original patch 4 which has been merged into the baseline.
Compared with v1:
- Redefine the RMID information.
- Refactor the resctrl_arch_rmid_idx_decode() and
resctrl_arch_rmid_idx_encode().
- Simplify closid_rmid2reqpartid() to rmid2reqpartid() and replace it
accordingly.
Compared with RFC-v4:
- Rebase the patch set on the v6.14-rc1 branch.
Compared with RFC-v3:
- Add limitation of the Narrow-PARTID feature (See Patch 2).
- Remove redundant reqpartid2closid() and reqpartid_pmg2rmid().
- Refactor closid_rmid2reqpartid() partially.
- Merge the PARTID conversion-related patches into a single patch for
bisectability.
- Skip adaptation of resctrl_arch_set_rmid() which is going to be
removed.
Compared with RFC-v2:
- Refactor closid/rmid pair translation.
- Simplify the logic of synchronize configuration.
- Remove reqPARTID source bitmap.
Compared with RFC-v1:
- Rebase this patch set on latest MPAM driver of the v6.12-rc1 branch.
v2: https://lore.kernel.org/all/20250222112448.2438586-1-zengheng4@huawei.com/
v1: 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/
---
Zeng Heng (9):
fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state
during umount
arm_mpam: Add intPARTID and reqPARTID support for narrow PARTID
feature
arm_mpam: Disable Narrow-PARTID when MBA lacks support
arm_mpam: Refactor rmid to reqPARTID/PMG mapping
arm_mpam: Propagate control group config to sub-monitoring groups
fs/resctrl: Add rmid_entry state helpers
arm_mpam: Implement dynamic reqPARTID allocation for monitoring groups
fs/resctrl: Wire up rmid expansion and reclaim functions
arm64/mpam: Add mpam_sync_config() for dynamic rmid expansion
arch/x86/include/asm/resctrl.h | 7 +
drivers/resctrl/mpam_devices.c | 83 ++++++---
drivers/resctrl/mpam_internal.h | 7 +-
drivers/resctrl/mpam_resctrl.c | 289 ++++++++++++++++++++++++++++----
fs/resctrl/monitor.c | 50 +++++-
fs/resctrl/rdtgroup.c | 24 ++-
include/linux/arm_mpam.h | 17 ++
include/linux/resctrl.h | 21 +++
8 files changed, 434 insertions(+), 64 deletions(-)
--
2.25.1
Hi Zeng, On 3/17/26 13:21, Zeng Heng wrote: > This series applies on top of the mpam_resctrl_glue_v5_debugfs branch of: > https://gitlab.arm.com/linux-arm/linux-bh.git > > Background > ========== > > On x86, the resctrl allows creating up to num_rmids monitoring groups > under parent control group. However, ARM64 MPAM is currently limited by > the PMG (Performance Monitoring Group) count, which is typically much > smaller than the theoretical RMID limit. This creates a significant > scalability gap: users expecting fine-grained per-process or per-thread > monitoring quickly exhaust the PMG space, even when plenty of reqPARTIDs > remain available. > > The Narrow-PARTID feature, defined in the ARM MPAM architecture, > addresses this by associating reqPARTIDs with intPARTIDs through a > programmable many-to-one mapping. This allows the kernel to present more > logical monitoring contexts. Thanks for this series and all your help with MPAM driver. Using PARTID narrowing to allow more resctrl monitoring groups is a good idea. > > Design Overview > =============== > > The implementation extends the RMID encoding to carry reqPARTID > information: > > RMID = reqPARTID * NUM_PMG + PMG > > In this patchset, a monitoring group is uniquely identified by the > combination of reqPARTID and PMG. The closid is represented by intPARTID, > which is exactly the original PARTID. > > For systems with homogeneous MSCs (all supporting Narrow-PARTID), the > driver exposes the full reqPARTID range directly. For heterogeneous > systems where some MSCs lack Narrow-PARTID support, the driver utilizes > PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring > capacity. The sole exception is when MBA MSCs lack Narrow-PARTID support, > their percentage-based control mechanism prevents the use of PARTIDs as > reqPARTIDs. We also need to consider how this will interact with cache capacity controls (CMAX/CMIN). Although, they are not exposed by the driver yet. > > Capacity Improvements > ===================== > > -------------------------------------------------------------------------- > The maximum | Sub-monitoring groups | System-wide > number of | under a control group | monitoring groups > -------------------------------------------------------------------------- > Without | | > reqPARTID | PMG | intPARTID * PMG > -------------------------------------------------------------------------- > reqPARTID | | > static allocation | (reqPARTID // intPARTID) * PMG | reqPARTID * PMG > -------------------------------------------------------------------------- > reqPARTID | | > dynamic allocation | (reqPARTID − intPARTID + 1) * PMG | reqPARTID * PMG > -------------------------------------------------------------------------- Does the quest for more monitoring groups stop here or do you see a usecase for limiting the number of control groups to get more monitoring groups? Thanks Ben
Hi Ben, On 2026/3/21 0:14, Ben Horgan wrote: > Hi Zeng, > > On 3/17/26 13:21, Zeng Heng wrote: >> This series applies on top of the mpam_resctrl_glue_v5_debugfs branch of: >> https://gitlab.arm.com/linux-arm/linux-bh.git >> >> Background >> ========== >> >> On x86, the resctrl allows creating up to num_rmids monitoring groups >> under parent control group. However, ARM64 MPAM is currently limited by >> the PMG (Performance Monitoring Group) count, which is typically much >> smaller than the theoretical RMID limit. This creates a significant >> scalability gap: users expecting fine-grained per-process or per-thread >> monitoring quickly exhaust the PMG space, even when plenty of reqPARTIDs >> remain available. >> >> The Narrow-PARTID feature, defined in the ARM MPAM architecture, >> addresses this by associating reqPARTIDs with intPARTIDs through a >> programmable many-to-one mapping. This allows the kernel to present more >> logical monitoring contexts. > > Thanks for this series and all your help with MPAM driver. Using PARTID > narrowing to allow more resctrl monitoring groups is a good idea. > >> >> Design Overview >> =============== >> >> The implementation extends the RMID encoding to carry reqPARTID >> information: >> >> RMID = reqPARTID * NUM_PMG + PMG >> >> In this patchset, a monitoring group is uniquely identified by the >> combination of reqPARTID and PMG. The closid is represented by intPARTID, >> which is exactly the original PARTID. >> >> For systems with homogeneous MSCs (all supporting Narrow-PARTID), the >> driver exposes the full reqPARTID range directly. For heterogeneous >> systems where some MSCs lack Narrow-PARTID support, the driver utilizes >> PARTIDs beyond the intPARTID range as reqPARTIDs to expand monitoring >> capacity. The sole exception is when MBA MSCs lack Narrow-PARTID support, >> their percentage-based control mechanism prevents the use of PARTIDs as >> reqPARTIDs. > > We also need to consider how this will interact with cache capacity controls > (CMAX/CMIN). Although, they are not exposed by the driver yet. For MSRs that support percentage-based control mechanisms, if Narrow- PARTID is not supported, the functionality needs to be rolled back. The limitation will be included in the next version. > >> >> Capacity Improvements >> ===================== >> >> -------------------------------------------------------------------------- >> The maximum | Sub-monitoring groups | System-wide >> number of | under a control group | monitoring groups >> -------------------------------------------------------------------------- >> Without | | >> reqPARTID | PMG | intPARTID * PMG >> -------------------------------------------------------------------------- >> reqPARTID | | >> static allocation | (reqPARTID // intPARTID) * PMG | reqPARTID * PMG >> -------------------------------------------------------------------------- >> reqPARTID | | >> dynamic allocation | (reqPARTID − intPARTID + 1) * PMG | reqPARTID * PMG >> -------------------------------------------------------------------------- > > Does the quest for more monitoring groups stop here or do you see a usecase > for limiting the number of control groups to get more monitoring groups? > Plan to build upon the original patches by introducing an enhancement that allows users to limit the number of control groups via a new boot parameter, with a range of [1, intpartid], thereby achieving the goal of expanding the number of monitoring groups. Thanks for your review comments. Best regards, Zeng Heng
© 2016 - 2026 Red Hat, Inc.