Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Reinette Chatre
Date: Tue Apr 21 2026 - 18:46:22 EST
Hi Babu,
On 4/21/26 3:04 PM, Moger, Babu wrote:
> My bad. My only motivation was to keep the mode listing display consistent.
The listing display is already inconsistent since the different modes have different
global properties, no?
>
> That said, I agree we need to support this. Without it, we won’t be able to move the group from PLZA to non-PLZA.
>
> # cat info/kernel_mode
> inherit_ctrl_and_mon:
> global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
> [global_assign_ctrl_assign_mon_per_cpu]:group=ctrl1/mon1/
Like above where the listing is inconsistent. Is this what you mean?
sidenote: Should the last line be "[global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]"?
>
> # echo "inherit_ctrl_and_mon:group=ctrl1/mon1/" > info/kernel_mode
This does not look right. Why is a "group" property needed here? Can the mode not just
be set by itself? Specifically, why not just:
# echo "inherit_ctrl_and_mon" > info/kernel_mode
This reminds me that there is still an open remaining from
https://lore.kernel.org/lkml/71099958-1ddf-40dc-8a3c-aa13d0c56fee@xxxxxxxxx/
Specifically this from that message:
The named fields could be made optional, if group is omitted then it will become the
default resource group, and if cpus/cpus_list is omitted then it will default to all CPUs.
This may not be intuitive since a user may expect that not mentioning a field means
that the field is left untouched. Have you considered this scenario in your proposal?
I think this needs some clear description of behavior wrt properties, for example:
- Is it required to provide all properties on each write? More specifically, can user expect there
to be "default" values when a property is not provided or is user required to provide a value
for each property? We need to be careful here because we do not want user scripts to fail when a new
property is added in the future. What if resctrl specifies that if user space does not provide
a property then resctrl will pick a default. For example, if user runs:
# echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
then resctrl will switch to "global_assign_ctrl_assign_mon_per_cpu" mode initialized to
the default group.
I am not sure if resctrl needs to support re-configuration of modes in the future where the
mode stays the same but a property changes? Consider, for example,
# cat info/kernel_mode
[inherit_ctrl_and_mon:]
global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
# echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
/*
* resctrl switches to "global_assign_ctrl_assign_mon_per_cpu" mode and sets
* PLZA group to default group
*/
# cat info/kernel_mode
inherit_ctrl_and_mon:
[global_assign_ctrl_assign_mon_per_cpu:group=//]
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" > info/kernel_mode
/*
* resctrl stays in "global_assign_ctrl_assign_mon_per_cpu" mode and sets
* PLZA group to default group
*/
# cat info/kernel_mode
inherit_ctrl_and_mon:
[global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
# echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
/*
* TBD: should resctrl switch back to default group or just keep
* group as ctrl1/mon1/ ?
*/
resctrl could thus specify different behavior for switching to a mode where all properties
not specified obtains default values and re-configuring a mode where only specified
properties are changed. That means, the "TBD" above would be that the group stays
as ctrl1/mon1/. So,
# cat info/kernel_mode
inherit_ctrl_and_mon:
[global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
What do you think?
> # cat info/kernel_mode
> inherit_ctrl_and_mon:
> global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
> [global_assign_ctrl_assign_mon_per_cpu]:group=uninitialized
This does not look right. After switching the kernel_mode to inherit_ctrl_and_mon
I expect inherit_ctrl_and_mon to be the active mode?
Reinette