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

["Moger, Babu" <bmoger@amd.com>]

Hi Reinette,

On 4/8/2026 6:41 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 4/8/26 4:07 PM, Moger, Babu wrote:
>> On 4/8/2026 4:24 PM, Reinette Chatre wrote:
>>> On 4/8/26 1:45 PM, Babu Moger wrote:
> ...
> 
>>>> The modes "global_assign_ctrl_inherit_mon_per_cpu" and "global_assign_ctrl_assign_mon_per_cpu" represent the actual PLZA modes.
>>>>
>>>> Both of these modes introduce new files kernel_mode_cpus/ and kernel_mode_cpus_list in the resctrl group.
>>>
>>> Right. To be specific when the user changes the mode to either "global_assign_ctrl_inherit_mon_per_cpu" or
>>> "global_assign_ctrl_assign_mon_per_cpu" the new files will be created in the default resource group with
>>> associated setting applied globally at that time.
>>
>> If, at that point, "info/kernel_mode_assignment" points to // (the default group), is that correct?
> 
> I see "info/kernel_mode_assignment" pointing to default group as the only
> option right after a mode switch away from "inherit_ctrl_and_mon".
> 
> To elaborate, the current idea is that the mode within info/kernel_mode determines
> which, if any, control files are presented to user space.
> Assuming that the system boots up with:
> 	# cat info/kernel_mode
> 	[inherit_ctrl_and_mon]
> 	global_assign_ctrl_inherit_mon_per_cpu
> 	global_assign_ctrl_assign_mon_per_cpu
> 
> In above scenario "info/kernel_mode_assignment" does not exist (is not visible to
> user space).
> 
> 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.

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.

This seems restrictive.

> 
> 
>> And if "info/kernel_mode_assignment" points to a different group
>> (for example, test//), then the kernel_mode_cpus/ and
>> kernel_mode_cpus_list files will be created only under the test//
>> group. Is that correct?
> 
> I expect that if "info/kernel_mode_assignment" exists then the group
> listed within contains kernel_mode_cpus and kernel_mode_cpuslist.
> How the group ends up in "info/kernel_mode_assignment" could result
> from mode change or from write by user space.
> 
Ack.

Thanks
Babu>