Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Moger, Babu
Date: Mon Apr 20 2026 - 19:00:29 EST
Hi Reinette,
On 4/20/2026 5:03 PM, Reinette Chatre wrote:
Hi Babu,
On 4/20/26 12:38 PM, Babu Moger wrote:
On 4/9/26 22:41, Reinette Chatre wrote:
On 4/9/26 4:42 PM, Moger, Babu wrote:Started working on these changes. May be it is better to discuss this before to avoid one more revision.
On 4/9/2026 3:50 PM, Reinette Chatre wrote:
Hi Babu,
On 4/9/26 11:05 AM, Moger, Babu wrote:
On 4/9/2026 12:26 PM, Reinette Chatre wrote:
On 4/9/26 10:19 AM, Moger, Babu wrote:
On 4/8/2026 6:41 PM, Reinette Chatre wrote:
When the user switches to either "global_assign_ctrl_inherit_mon_per_cpu" or
'global_assign_ctrl_assign_mon_per_cpu" then "info/kernel_mode_assignment" is created
(or made visible to user space) and is expected to point to default group.
User can change the group using "info/kernel_mode_assignment" at this point.
If the current scenario is below ...
# cat info/kernel_mode
[global_assign_ctrl_inherit_mon_per_cpu]
inherit_ctrl_and_mon
global_assign_ctrl_assign_mon_per_cpu
... then "info/kernel_mode_assignment" will exist but what it should contain if
user switches mode at this point may be up for discussion.
option 1)
When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
the resource group in "info/kernel_mode_assignment" is reset to the
default group and all CPUs PLZA state reset to match. The kernel_mode_cpus
and kernel_mode_cpuslist files become visible in default resource group
and they contain "all online CPUs".
option 2)
When user switches mode to "global_assign_ctrl_assign_mon_per_cpu" then
the resource group in "info/kernel_mode_assignment" is kept and all
CPUs PLZA state set to match it while also keeping the current
values of that resource group's kernel_mode_cpus and kernel_mode_cpuslist
files.
I am leaning towards "option 1" to keep it consistent with a switch from
"inherit_ctrl_and_mon" and being deterministic about how a mode is started with
Yes. The "option 1" seems appropriate.
a clean slate. What are your thoughts? What would be use case where a user would
want to switch between "global_assign_ctrl_inherit_mon_per_cpu" and
"global_assign_ctrl_assign_mon_per_cpu" to just switch rmid_en on and off?
This is a bit tricky.
Currently, our requirement is to have a CTRL_MON group for
global_assign_ctrl_inherit_mon_per_cpu. In this scenario, we use the
group’s CLOSID for PLZA configuration, and RMID is not used (rmid_en
= 0) when setting up PLZA.
Our requirement is also to have a CTRL_MON/MON group for
global_assign_ctrl_assign_mon_per_cpu. In this case as well, the
group’s CLOSID and RMID (rmid_en = 1) both are used configure PLZA.
ah, right. Good catch.
Actually, we should not allow these changes from
global_assign_ctrl_inherit_mon_per_cpu to
global_assign_ctrl_assign_mon_per_cpu or visa versa.
resctrl could allow it but as part of the switch it resets the "kernel mode group" to
be the default group every time? This would be the "option 1" above.
Other options.
Allow global_assign_ctrl_inherit_mon_per_cpu -> global_assign_ctrl_assign_mon_per_cpu. As part of the switch, reset the "kernel mode group" to the default group.
Allow global_assign_ctrl_assign_mon_per_cpu -> global_assign_ctrl_inherit_mon_per_cpu. In this case switch
to CTRL_MON/MON -> CTRL_MON.
ok. Could you please return the courtesy of providing feedback on the
suggestion you are responding to and also include the motivation why your
suggestion is the better option?
Yea. Sure.
We need to allow the switch between the modes. Otherwise only way to reset is to remount the resctrl filesystem. That is not a good option.
Allow global_assign_ctrl_inherit_mon_per_cpu -> global_assign_ctrl_assign_mon_per_cpu. As part of the switch, reset the "kernel mode group" to the default group.
This option is same as you suggested.
Allow global_assign_ctrl_assign_mon_per_cpu -> global_assign_ctrl_inherit_mon_per_cpu. In this case switch
to CTRL_MON/MON -> CTRL_MON. This option basically disables monitor (rmid_en=0). It is less disruptive. Move is between child group to parent group.
ok. I am concerned that this creates an inconsistent interface. Specifically, sometimes
when switching the mode the kernel group will reset and sometimes it won't. This inconsistency
may be more apparent when writing the user documentation as part of this work. If you are
able to clearly explain how this resctrl fs interface behaves (this cannot be about PLZA
internals as above) then this could work.
The current mode change behavior is very restrictive.
For example:
# cat info/kernel_mode
inherit_ctrl_and_mon
[global_assign_ctrl_assign_mon_per_cpu]
global_assign_ctrl_inherit_mon_per_cpu
# cat info/kernel_mode_assignment
ctrl1/mon1/
In this state, we cannot change kernel_mode to inherit_ctrl_and_mon. The expectation, however, is that inherit_ctrl_and_mon should always map to the RDTCTRL_GROUP.
Could you please provide details behind the "we cannot change kernel_mode to
inherit_ctrl_and_mon" statement? Why is this not possible?
I do not see "inherit_ctrl_and_mon" to map to *any* group though. Expectation is
that when user changes mode to "inherit_ctrl_and_mon" then
info/kernel_mode_assignment would become invisible to user space.
Ok. That is fine.
Sorry for not making it clear. Let’s consider the following scenario.
The system boots with these default settings:
# cat info/kernel_mode
[inherit_ctrl_and_mon]
global_assign_ctrl_assign_mon_per_cpu
global_assign_ctrl_inherit_mon_per_cpu
At this point, the interface info/kernel_mode_assignment is not visible.
Next, lets create a new control group:
# mkdir ctrl1
We want to designate this group as the new kernel-mode group.
First operation: Change the mode:
# echo "global_assign_ctrl_inherit_mon_per_cpu" > info/kernel_mode
At this stage, only the kernel mode is being changed. However, there is no way to know which control group the user intends to assign to kernel mode. All we know here is the selected mode.
After this operation, the info/kernel_mode_assignment interface should become visible. But the question is: what should it contain or point to at this moment?
# cat info/kernel_mode_assignment
??
Next operation: Assign the group
# echo "ctrl1//" > info/kernel_mode_assignment
Now the intended control group (ctrl1) is explicitly specified for kernel mode. In summary, changing the kernel mode requires two distinct inputs:
- Selecting the kernel mode.
- Specifying the control group to be used for that mode.
Hope this makes sense.
Thanks
Babu
A similar issue exists when switching between
global_assign_ctrl_inherit_mon_per_cpu and
global_assign_ctrl_assign_mon_per_cpu (in either direction).
What similar issue? Could you please provide some detail to help me understand what the
issue is? Isn't this what we just discussed in thread you are replying to? That is, you were
looking at developing that interface that I viewed as "inconsistent"?
The same problem also occurs when modifying the kernel_mode_assignment group. If the current group is an RDTMON_GROUP, we can't assign another
RDTCTRL_GROUP without changing both mode and group together.
Same problem? Still unclear what the problem is. So far three problems are mentioned but I am
not able to decipher what the problems are. Could you please elaborate?
When modifying the kernel_mode_assignment group I expect that the interface
will only accept a MON group when in "assign_mon" mode and a CTRL group when
in "inherit_mon" mode.
I do not understand what you mean with *another* RDTCTRL_GROUP. Only one group
can be assigned at any time, no?
Reinette