Re: [RFC PATCH 13/19] x86/resctrl: Add PLZA state tracking and context switch handling

[Reinette Chatre]

Hi Babu,

On 2/23/26 2:35 PM, Moger, Babu wrote:
> On 2/23/2026 11:12 AM, Reinette Chatre wrote:
>> On 2/20/26 2:44 PM, Moger, Babu wrote:
>>> On 2/19/2026 8:53 PM, Reinette Chatre wrote:

>>>> info/kernel_mode
>>>> ================
>>>> - Displays the currently active as well as possible features available to user
>>>>     space.
>>>> - Single place where user can query "kernel mode" behavior and capabilities of the
>>>>     system.
>>>> - Some possible values:
>>>>     - inherit_ctrl_and_mon <=== previously named "match_user", just renamed for consistency with other names
>>>>        When active, kernel and user space use the same CLOSID/RMID. The current status
>>>>        quo for x86.
>>>>     - global_assign_ctrl_inherit_mon
>>>>        When active, CLOSID/control group can be assigned for *all* (hence, "global")
>>>>        kernel work while all kernel work uses same RMID as user space.
>>>>        Can only be supported on architecture where CLOSID and RMID are independent.
>>>>        An arch may support this in hardware (RMID_EN=0?) or this can be done by resctrl during
>>>>        context switch if the RMID is independent and the context switches cost is
>>>>        considered "reasonable".
>>>>        This supports use case https://lore.kernel.org/lkml/CABPqkBSq=cgn-am4qorA_VN0vsbpbfDePSi7gubicpROB1=djw@xxxxxxxxxxxxxx/
>>>>        for PLZA.
>>>>     - global_assign_ctrl_assign_mon
>>>>        When active the same resource group (CLOSID and RMID) can be assigned to
>>>>        *all* kernel work. This could be any group, including the default group.
>>>>        There may not be a use case for this but it could be useful as an intemediate
>>>>        step of the mode that follow (more later).
>>>>     - per_group_assign_ctrl_assign_mon
>>>>        When active every resource group can be associated with another (or the same)
>>>>        resource group. This association maps the resource group for user space work
>>>>        to resource group for kernel work. This is similar to the "kernel_group" idea
>>>>        presented in:
>>>>        https://lore.kernel.org/lkml/aYyxAPdTFejzsE42@xxxxxxxxxxxxxxx/
>>>>        This addresses use case https://lore.kernel.org/lkml/CABPqkBSq=cgn-am4qorA_VN0vsbpbfDePSi7gubicpROB1=djw@xxxxxxxxxxxxxx/
>>>>        for MPAM.
>>>
>>> All these new names and related information will go in global structure.
>>>
>>> Something like this..
>>>
>>> Struct kern_mode {
>>>         enum assoc_mode;
>>>         struct rdtgroup *k_rdtgrp;
>>>         ...
>>> };
>>>
>>> Not sure what other information will be required here. Will know once I stared working on it.
>>>
>>> This structure will be updated based on user echo's in "kernel_mode" and "kernel_mode_assignment".
>>
>> This looks to be a good start. I think keeping the rdtgroup association is good since
>> it helps to easily display the name to user space while also providing access to the CLOSID
>> and RMID that is assigned to the tasks.
>> By placing them in their own structure instead of just globals it does make it easier to
>> build on when some modes have different requirements wrt rdtgroup management.
> 
> I am not clear on this comment. Can you please elaborate little bit?

I believe what you propose should suffice for the initial support for PLZA. I do not
see the PLZA enabling needing anything more complicated.

As I understand for MPAM support there needs to be more state to track which privilege level
tasks run at.

So, when just considering how MPAM may build on this: The PARTID/PMG to run at when in kernel mode
can be managed per group or per task. In either case I suspect that struct task_struct would need
to include the kernel mode PARTID/PMG to support setting the correct kernel mode PARTID/PMG during
context switching similar to what you coded up in this initial RFC. MPAM may choose to have struct
task_struct be the only place to keep all state about which PARTID/PMG to run when in kernel mode
but I suspect that may result in a lot of lock contention (user space could, for example, be able
to lock up the entire system with a loop reading info/kernel_mode_assignment) so MPAM may choose to
expand the struct kernel_mode introduced by PLZA to, (if kernel mode is managed per group) instead
of one struct rdtgroup * contain a mapping of every resource group to the resource group that should
be used for kernel mode work. This could be some staging/cache used between user space and all the
task structures to help manage the state.

I do not know what MPAM implementation may choose to do but as I see it your proposal 
provides a good foundation to build on since it establishes a global place, struct kernel_mode,
where all such state can/should be stored instead of some unspecified group of global variables.

Reinette