Re: [PATCH v5 RESEND 5/7] fs/resctrl: Release the limbo RMIDs when the CDP state changes

[Ben Horgan <ben.horgan@arm.com>]

Hi Reinette, Jinjie,

On 11/11/2026 18:33, Reinette Chatre wrote:
> Hi Jinjie,
> 
> On 11/10/26 5:39 AM, Jinjie Ruan wrote:
> 
>> still carry those RMIDs are accounted to the next user of each RMID.
>>
>> The CDP state that matters is the one that changes the PARTIDs used by
>> the monitors, which is not necessarily the CDP state of the L3
>> resource. MPAM gives every CLOSID two PARTIDs in all MSCs while CDP is
>> enabled on any resource, so enabling CDP on L2 alone also changes the
>> PARTIDs the L3 monitors use. Add resctrl_arch_mon_cdp_enabled() to let
>> the architecture report this. Only MPAM can be affected, so the RMIDs
>> are only released where the RMID depends on the CLOSID. On x86 the
>> RMID does not depend on the CLOSID, and resctrl_arch_mon_cdp_enabled()
>> returns false.
> 
> nack. The helper name and value returned on x86 is the first hint that this
> is not right. For x86 the value is not a statement about x86: CDP exists on
> x86 and can be enabled, so a function called resctrl_arch_mon_cdp_enabled()
> returning false reads as wrong until the comment above it explains that what
> is really being reported is whether CDP changes the IDs the monitors use.

The invariant that the limbo handler is currently relying on is that the
mapping of rmid index to the underlying hardware monitor index is fixed.
For MPAM, if cdp is enabled at all then the mapping is changed and so
the invariant does not hold between mounts. MPAM's emulation of CDP is
why it breaks the invariant. resctrl shouldn't need to care about this
MPAM specific reason and should only care whether or not the invariant
is upheld or not. In the future, MPAM may use more than the two existing
indexing schemes. For instance, if we wanted to have one memory
bandwidth monitor per monitor group, without assignment, then we would
need to limit the number of monitor groups.

> 
> Every architecture now needs to match this. This looks more like forcing
> every architecture to indicate whether it has the same quirk as MPAM.
> 
> If there is no way to handle this in MPAM driver then handling this should at
> least be contained between resctrl filesystem and MPAM driver. This should not
> be forced on all architectures.

I don't see a way for the MPAM to keep the same RMID for when it is
emulating CDP and when it's not.

> 
> I trust the MPAM folks to say whether it can or cannot be done in MPAM driver.
> If this is not possible in MPAM driver then it looks like this needs to go back
> to include the L2 CDP check as was done in previous version. With this check 
> gated by IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID) it does hint "MPAM"
> but would also need a comment to explain why that is done.
> 

Would something like an rmid indexing generation count be any better or
is that just overthinking it?

int resctrl_arch_rmid_indexing_generation(void);

If the indexing never changes the arch could always return 1 and if it
does change the architecture can bump the number on every change. It
would still never change when resctrl is mounted.

Thanks,

Ben