drivers/resctrl/mpam_devices.c | 1 + 1 file changed, 1 insertion(+)
When resctrl is unmounted, MPAM components should be reset to default
configurations to avoid impacting system performance. However, after
a user updates MPAM configuration via mpam_apply_config(), the
in_reset_state flag remains true, causing mpam_reset_ris() to skip
the actual register restoration on subsequent resets.
For example, after mounting resctrl and modifying the root group's
schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
would leave the modified MPAM settings in hardware registers since
mpam_reset_ris() returns early due to in_reset_state still being true.
This results in persistent performance restrictions even after resctrl
is umounted.
Fix by clearing in_reset_state to false immediately after successful
configuration application, ensuring that the next reset operation
properly restores MPAM register defaults.
Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
The in_reset_state state machine has been carefully reviewed, particularly
the handling in mpam_cpu_online() where the flag is checked before
applying configurations. in_reset_state indicates whether the RIS is
currently using default configurations. This change aligns with the
original design intent and does not introduce semantic breakage to
existing state transitions.
---
drivers/resctrl/mpam_devices.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
index 460ea98a1c92..044227ee033f 100644
--- a/drivers/resctrl/mpam_devices.c
+++ b/drivers/resctrl/mpam_devices.c
@@ -2932,6 +2932,7 @@ int mpam_apply_config(struct mpam_component *comp, u16 partid,
srcu_read_lock_held(&mpam_srcu)) {
arg.ris = ris;
mpam_touch_msc(msc, __write_config, &arg);
+ ris->in_reset_state = false;
}
mutex_unlock(&msc->cfg_lock);
}
--
2.25.1
Hi Zeng,
On 2/13/26 07:50, Zeng Heng wrote:
> When resctrl is unmounted, MPAM components should be reset to default
> configurations to avoid impacting system performance. However, after
> a user updates MPAM configuration via mpam_apply_config(), the
> in_reset_state flag remains true, causing mpam_reset_ris() to skip
> the actual register restoration on subsequent resets.
>
> For example, after mounting resctrl and modifying the root group's
> schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
nit: MBMIN isn't currently supported in resctrl. I'd just drop the
part in brackets.
> would leave the modified MPAM settings in hardware registers since
> mpam_reset_ris() returns early due to in_reset_state still being true.
> This results in persistent performance restrictions even after resctrl
> is umounted.
>
> Fix by clearing in_reset_state to false immediately after successful
> configuration application, ensuring that the next reset operation
> properly restores MPAM register defaults.
>
> Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
mpam_apply_config() doesn't exist in this commit. I would have expected:
Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
The change and justification looks good to me.
Acked-by: Ben Horgan <ben.horgan@arm.com>
Thanks,
Ben
> ---
> The in_reset_state state machine has been carefully reviewed, particularly
> the handling in mpam_cpu_online() where the flag is checked before
> applying configurations. in_reset_state indicates whether the RIS is
> currently using default configurations. This change aligns with the
> original design intent and does not introduce semantic breakage to
> existing state transitions.
> ---
> drivers/resctrl/mpam_devices.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 460ea98a1c92..044227ee033f 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -2932,6 +2932,7 @@ int mpam_apply_config(struct mpam_component *comp, u16 partid,
> srcu_read_lock_held(&mpam_srcu)) {
> arg.ris = ris;
> mpam_touch_msc(msc, __write_config, &arg);
> + ris->in_reset_state = false;
> }
> mutex_unlock(&msc->cfg_lock);
> }
> --
> 2.25.1
>
On 2/17/26 15:59, Ben Horgan wrote:
> Hi Zeng,
>
> On 2/13/26 07:50, Zeng Heng wrote:
>> When resctrl is unmounted, MPAM components should be reset to default
>> configurations to avoid impacting system performance. However, after
>> a user updates MPAM configuration via mpam_apply_config(), the
>> in_reset_state flag remains true, causing mpam_reset_ris() to skip
>> the actual register restoration on subsequent resets.
>>
>> For example, after mounting resctrl and modifying the root group's
>> schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
>
> nit: MBMIN isn't currently supported in resctrl. I'd just drop the
> part in brackets.
>
>> would leave the modified MPAM settings in hardware registers since
>> mpam_reset_ris() returns early due to in_reset_state still being true.
>> This results in persistent performance restrictions even after resctrl
>> is umounted.
>>
>> Fix by clearing in_reset_state to false immediately after successful
>> configuration application, ensuring that the next reset operation
>> properly restores MPAM register defaults.
>>
>> Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
>
> mpam_apply_config() doesn't exist in this commit. I would have expected:
> Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
>
>> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
>
> The change and justification looks good to me.
>
> Acked-by: Ben Horgan <ben.horgan@arm.com>
>
I'll add this on to the start of the current mpam resctrl series as even
though this is squashing an existing bug it can't be hit until mpam has
a user interface and so doesn't need to go as a fix.
Thanks,
Ben
Hi Ben,
On 2026/2/27 22:16, Ben Horgan wrote:
>
>
> On 2/17/26 15:59, Ben Horgan wrote:
>> Hi Zeng,
>>
>> On 2/13/26 07:50, Zeng Heng wrote:
>>> When resctrl is unmounted, MPAM components should be reset to default
>>> configurations to avoid impacting system performance. However, after
>>> a user updates MPAM configuration via mpam_apply_config(), the
>>> in_reset_state flag remains true, causing mpam_reset_ris() to skip
>>> the actual register restoration on subsequent resets.
>>>
>>> For example, after mounting resctrl and modifying the root group's
>>> schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
>>
>> nit: MBMIN isn't currently supported in resctrl. I'd just drop the
>> part in brackets.
>>
>>> would leave the modified MPAM settings in hardware registers since
>>> mpam_reset_ris() returns early due to in_reset_state still being true.
>>> This results in persistent performance restrictions even after resctrl
>>> is umounted.
>>>
>>> Fix by clearing in_reset_state to false immediately after successful
>>> configuration application, ensuring that the next reset operation
>>> properly restores MPAM register defaults.
>>>
>>> Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
>>
>> mpam_apply_config() doesn't exist in this commit. I would have expected:
>> Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
>>
>>> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
>>
>> The change and justification looks good to me.
>>
>> Acked-by: Ben Horgan <ben.horgan@arm.com>
>>
>
> I'll add this on to the start of the current mpam resctrl series as even
> though this is squashing an existing bug it can't be hit until mpam has
> a user interface and so doesn't need to go as a fix.
>
> Thanks,
>
> Ben
>
>
OK, get it.
Best regards,
Zeng Heng
© 2016 - 2026 Red Hat, Inc.