Re: [RFC PATCH 13/19] x86/resctrl: Add PLZA state tracking and context switch handling
From: Babu Moger
Date: Tue Feb 24 2026 - 14:38:02 EST
Hi Reinette,
On 2/23/26 17:13, Reinette Chatre wrote:
Hi Babu,Sounds good. Thanks for the clarification.
On 2/23/26 2:35 PM, Moger, Babu wrote:
On 2/23/2026 11:12 AM, Reinette Chatre wrote:I believe what you propose should suffice for the initial support for PLZA. I do not
On 2/20/26 2:44 PM, Moger, Babu wrote:I am not clear on this comment. Can you please elaborate little bit?
On 2/19/2026 8:53 PM, Reinette Chatre wrote:This looks to be a good start. I think keeping the rdtgroup association is good since
info/kernel_modeAll these new names and related information will go in global structure.
================
- 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.
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".
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.
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.
Thanks
Babu