Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Reinette Chatre
Date: Mon Apr 20 2026 - 19:39:07 EST
Hi Babu,
On 4/20/26 3:59 PM, Moger, Babu wrote:
> On 4/20/2026 5:03 PM, Reinette Chatre wrote:
>> On 4/20/26 12:38 PM, Babu Moger wrote:
>>> 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?
This was considered as part of original proposal per
https://lore.kernel.org/lkml/2ab556af-095b-422b-9396-f845c6fd0342@xxxxxxxxx/
(search for "default value") where the idea was that the group
should be initialized to the default group.
>
> # cat info/kernel_mode_assignment
> ??
After
# echo "global_assign_ctrl_inherit_mon_per_cpu" > info/kernel_mode
# cat info/kernel_mode_assignment
/
After
# echo "global_assign_ctrl_assign_mon_per_cpu" > info/kernel_mode
# cat info/kernel_mode_assignment
//
(although this is where previous discussion comes in on how interface
can become inconsistent depending on what the previous kernel mode was)
>
> 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.
>
Understood. Could you please elaborate what the problem is with making it so?
Are you trying to eliminate one per-CPU register write? Is this something that
ends up being very expensive? I assumed that a register designed to support
modification during context switch should be fast. Or is it the IPI you are
concerned about? Please help me to understand what the actual problem is that
you are trying to solve.
I think it is reasonable to start with defaults when changing the mode which
I do not expect users to change often.
Reinette