Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Babu Moger
Date: Tue Apr 21 2026 - 14:20:30 EST
Hi Reinette,
On 4/21/26 12:35, Reinette Chatre wrote:
Hi Babu,
On 4/21/26 9:46 AM, Babu Moger wrote:
On 4/21/26 11:15, Reinette Chatre wrote:
On 4/21/26 8:08 AM, Babu Moger wrote:
It sounds like we are saying the same thing?
When considering all the sharp corners I agree that keeping kernel_mode_cpus/kernel_mode_cpuslist
seems most user friendly. When doing so there is no need to include CPU assignment in the global
files.
Actually, I was talking about removing _per_cpu extension also as the per-CPU requirement is handled inside the group using kernel_mode_cpus/kernel_mode_cpuslist. It can be documented.
global_assign_ctrl_assign_mon_per_cpu -> global_assign_ctrl_assign_mon
global_assign_ctrl_inherit_mon_per_cpu -> global_assign_ctrl_inherit_mon
I see. The goal with this name choice was to distinguish a global mode that
additionally supports per-CPU assignment from a "true/pure" global mode that
does not support per-CPU assignment.
If resctrl ever needs to support such "true/pure" global mode that does
not support per-CPU assignment then resctrl will need to either come up with
a new mode that does not expose kernel_mode_cpus/kernel_mode_cpuslist or
make kernel_mode_cpus/kernel_mode_cpuslist read-only. The latter adds the
complication that user space can always change the mode of a file so resctrl
would need to add corner cases for that.
To me the "per_cpu" distinction is useful since it make it clear to user space
that even though this is a "global" configuration it additionally supports
per-CPU assignment for which user space can expect kernel_mode_cpus/kernel_mode_cpuslist
to exist and be writable. To me this makes the interface clear and intuitive.
ok. Sure.
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
Why do we still need to keep the "inherit_ctrl_and_mon"? By default all the groups in the system falls in this category it is not plza enabled group.
System boots up with following options if PLZA is supported.
# cat info/kernel_mode
global_assign_ctrl_assign_mon_per_cpu
global_assign_ctrl_inherit_mon_per_cpu
No groups are associated with kernel mode at this point.
To me it seems useful to be clear to user space on what the current mode is. If I understand correctly
above default scenario essentially means "inherit_ctrl_and_mon" but instead of adding it to this file
we will need to add documentation that describes to user space how this file should be interpreted.
It seems easier to me to just be clear via info/kernel_mode itself on what the current active mode is?
I think something like below will be more intuitive and not need much additional
documentation to understand (I am just adding the "uninitialized" as an example to match text
printed in schemata file during pseudo-locking ... even if there is a group named "uninitialized"
the lack of "/" could be used to make it clear what this means?):
# cat info/kernel_mode
[inherit_ctrl_and_mon]
global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
Sounds ok to me.
I also think an interface like this would be simpler for user space to use as it (user space) switches
between PLZA capable and non-PLZA capable systems since user space need not associate existence of
the file with some kernel mode state in addition to actual content of the file when it does exist.
I assumed that info/kernel_mode can just always be made visible and not depend on PLZA
capable hardware. This means that on Intel and Arm this file can show:
# cat info/kernel_mode
[inherit_ctrl_and_mon]
Yes. Sure.
For Intel this is accurate and also for Arm if I interpret the Arm implementation correctly
(see mpam_thread_switch()) in https://lore.kernel.org/lkml/20260313144617.3420416-7-ben.horgan@xxxxxxx/
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" > info/kernel_mode
# cat info/kernel_mode
global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
global_assign_ctrl_inherit_mon_per_cpu
# echo "global_assign_ctrl_inherit_mon_per_cpu:group=//" > info/kernel_mode
# cat info/kernel_mode
global_assign_ctrl_assign_mon_per_cpu
global_assign_ctrl_inherit_mon_per_cpu:group=//
How does this look?
In addition to above I think it will be helpful to add a clear indication to user
space on what the current active mode is, for example, via the [] characters.
# echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/" > info/kernel_mode
# 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/
Something like this?
How about making it clear that the whole line/configuration is active, like below:
# 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/]
ok. Sure.
There is one problem here. The mode "inherit_ctrl_and_mon" listing not consistent with others.
It is difficult to predict what resctrl will be asked to support next. One possibility here is
to make it part of the original design that the first field is the "mode" and the following field
contains that mode's global properties of which there could be more than one. Above shows that
the two "global" modes have a single global property but we could just try to be safe with some
documentation that states there could be more.
Consider for example some hypothetical future where the file looks like:
# cat info/kernel_mode
inherit_ctrl_and_mon:some_unique_capability=true
global_assign_ctrl_assign_mon_per_cpu:group=uninitialized;other_property=val
[global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
To leave room for growth the file could start out by, for example, appending ":"
to "inherit_ctrl_and_mon" to indicate that there are no known properties yet? Something like
below. Would this be more consistent with the others?
To me, it might be clearer to simply document what the default mode is when kernel mode is not enabled, and omit "inherit_ctrl_and_mon" from the display.
That said, I’m fine with either approach.
Thanks
Babu