Re: [RFC PATCH mpam mpam/snapshot/v6.12-rc1 v3 0/5] arm_mpam: Introduce the Narrow-PARTID feature for MPAM driver

[Dave Martin <Dave.Martin@arm.com>]

Hi,

On Sat, Dec 07, 2024 at 05:21:31PM +0800, Zeng Heng wrote:
> The patch set is applied for mpam/snapshot/v6.12-rc1 branch of
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git
> repository.
> 
> The narrow-partid feature in MPAM allows for a more efficient use of
> PARTIDs by enabling a many-to-one mapping of reqpartids (requested PARTIDs)
> to intpartids (internal PARTIDs). This mapping reduces the number of unique
> PARTIDs needed, thus allowing more tasks or processes to be monitored and
> managed with the available resources.
> 
> For a mixture of MSCs system, for MSCs that do not support narrow-partid,
> we use the PARTIDs exceeding the number of closids as reqPARTIDs for
> expanding the monitoring groups.

Mixed systems still seem not to be handled completely by this series?

You do cope with the scenario where some MSCs support Narrowing and
some do not, but there is still the problem of incompatible controls.

If a non-Narrowing MSC has controls that are not of the "partition
bitmap" type, then splitting a resctrl control group across multiple
PARTIDs is going to change the hardware regulation behaviour.  There
does not seem to be any way to work around this be programming
different control values (for example).  So, there may be over- or
under-allocation of resources compared with what the user requests in
resctrlfs.

So, I think there is still a need to check which controls are present,
and either disable the use of non-identity intPARTID<->reqPARTID
mappings if incompatible controls are present (or don't expose those
controls to resctrl).

(If you were not trying to address this issue yet then that is not a
problem for an RFC, but it is best to be clear about the
limitations...)

> In order to keep the existing resctrl API interface, the rmid contains both
> req_idx and PMG information instead of PMG only under the MPAM driver. The
> req_idx represents the req_idx-th sub-monitoring group under the control
> group. The new rmid would be like:
> 
>     rmid = (req_idx << shift | pmg).
> 
> The new conversion relationship between closid/rmid and (req)PARTID/PMG is:
> 
>     (req)PARTID = (rmid.req_idx * n) + closid,
>     PMG = rmid.pmg.
> 
> Each intPARTID has m reqPARTIDs, which are used to expand the number of
> monitoring groups under the control group. Therefore, the number of
> monitoring groups is no longer limited by the range of MPAM PMG, which
> enhances the extensibility of the system's monitoring capabilities.
> 
> ---
> Compared with v1:
>   - Rebase this patch set on latest MPAM driver of the v6.12-rc1 branch.
> 
> Compared with v2:
>   - Refactor closid/rmid pair translation
>   - Simplify the logic of synchronize configuration
>   - Remove reqPARTID pool
> ---

This approach looks reasonable overall, and in this version the changes
do seem to be better localised in the mpam_resctrl.c glue code now.

I had also been working on a similar approach, so I have posted it for
comparison [1] -- though the two approaches are doing pretty much the
same thing, some details differ.

(Note, I have not addressed PARTID Narrowing at all yet; however,
I think more thought is needed for that.)


Note: Are there bisection issues with some of the patches in the
series?  It looks like not all of the ID conversions are applied in the
same patch, so I'm wondering whether strange behaviour may be seen at
the intermediate commits.

Cheers
---Dave


[1] [RFC PATCH 0/6] Introduce flexible CLOSID/RMID translation
https://lore.kernel.org/lkml/20241212154000.330467-1-Dave.Martin@arm.com/