Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem

[Moger, Babu]

Hi Reinette,

On 4/20/2026 6:34 PM, Reinette Chatre wrote:
> 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)

This operation effectively promotes the default group (CLOSID 0) to the 
kernel-mode group. Consequently, MSRs will be programmed on all threads, 
which is not the user’s intent.

> > Next operation: Assign the group
> >
> > # echo "ctrl1//" > info/kernel_mode_assignment

Once again, this causes MSRs to be programmed with a new CLOSID(ctrl1) 
which is actual intended result.

> > 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.

Note that these MSR writes are not occurring in the context-switch path.

However, every time the kernel mode is changed, we end up performing an 
additional set of MSR writes, which is unnecessary overhead.

There is also another issue, as previously discussed: switching between
global_assign_ctrl_assign_mon_per_cpu and
global_assign_ctrl_inherit_mon_per_cpu, and vice versa.

One mode requires a CTRL_MON group, while the other requires a MON 
group. Because of this mismatch in required group types, switching 
between these modes is not possible.

We already discussed moving back to the default group on every mode 
switch. Doing so here would once again cause extra MSR writes on each 
mode transition, which is undesirable.

Thanks
Babu