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

[Luck, Tony]

On Fri, Feb 13, 2026 at 10:37:48AM -0600, Moger, Babu wrote:
> Hi Reinette,
> 
> On 2/10/2026 10:17 AM, Reinette Chatre wrote:
> > Hi Babu,
> > 
> > On 1/28/26 9:44 AM, Moger, Babu wrote:
> > > 
> > > 
> > > On 1/28/2026 11:41 AM, Moger, Babu wrote:
> > > > > On Wed, Jan 28, 2026 at 10:01:39AM -0600, Moger, Babu wrote:
> > > > > > On 1/27/2026 4:30 PM, Luck, Tony wrote:
> > > > > Babu,
> > > > > 
> > > > > I've read a bit more of the code now and I think I understand more.
> > > > > 
> > > > > Some useful additions to your explanation.
> > > > > 
> > > > > 1) Only one CTRL group can be marked as PLZA
> > > > 
> > > > Yes. Correct.
> > 
> > Why limit it to one CTRL_MON group and why not support it for MON groups?
> 
> There can be only one PLZA configuration in a system. The values in the
> MSR_IA32_PQR_PLZA_ASSOC register (RMID, RMID_EN, CLOSID, CLOSID_EN) must be
> identical across all logical processors. The only field that may differ is
> PLZA_EN.
> 
> I was initially unsure which RMID should be used when PLZA is enabled on MON
> groups.
> 
> After re-evaluating, enabling PLZA on MON groups is still feasible:
> 
> 1. Only one group in the system can have PLZA enabled.
> 2. If PLZA is enabled on CTRL_MON group then we cannot enable PLZA on MON
> group.
> 3. If PLZA is enabled on the CTRL_MON group, then the CLOSID and RMID of the
> CTRL_MON group can be written.
> 4. If PLZA is enabled on a MON group, then the CLOSID of the CTRL_MON group
> can be used, while the RMID of the MON group can be written.
> 
> I am thinking this approach should work.

I can see why a user might want to accumulate all kerrnel resource usage
in one RMID, separately from application resource usage. But wanting to
subdivide that between different tasks seems a stretch.

Remember that there are 3 main reasons why the kernel may be entered
while an application is running:

1) Application makes a system call
2) A trap or fault (most common = pagefault?)
3) An interrupt

The application has some limited control over 1 & 2. None at
all over 3.

So I'd like to hear some real use cases before resctrl commits
to adding this complexity.

> 
> > 
> > Limiting it to a single CTRL group seems restrictive in a few ways:
> > 1) It requires that the "PLZA" group has a dedicated CLOSID. This reduces the
> >     number of use cases that can be supported. Consider, for example, an existing
> >     "high priority" resource group and a "low priority" resource group. The user may
> >     just want to let the tasks in the "low priority" resource group run as "high priority"
> >     when in CPL0. This of course may depend on what resources are allocated, for example
> >     cache may need more care, but if, for example, user is only interested in memory
> >     bandwidth allocation this seems a reasonable use case?
> > 2) Similar to what Tony [1] mentioned this does not enable what the hardware is
> >     capable of in terms of number of different control groups/CLOSID that can be
> >     assigned to MSR_IA32_PQR_PLZA_ASSOC. Why limit PLZA to one CLOSID?
> > 3) The feature seems to support RMID in MSR_IA32_PQR_PLZA_ASSOC similar to
> >     MSR_IA32_PQR_ASSOC. With this, it should be possible for user space to, for
> >     example, create a resource group that contains tasks of interest and create
> >     a monitor group within it that monitors all tasks' bandwidth usage when in CPL0.
> >     This will give user space better insight into system behavior and from what I can
> >     tell is supported by the feature but not enabled?
> 
> 
> Yes, as long as PLZA is enabled on only one group in the entire system
> 
> > 
> > > > 
> > > > > 2) It can't be the root/default group
> > > > 
> > > > This is something I added to keep the default group in a un-disturbed,
> > 
> > Why was this needed?
> > 
> 
> With the new approach mentioned about we can enable in default group also.
> 
> > > > 
> > > > > 3) It can't have sub monitor groups
> > 
> > Why not?
> 
> Ditto. With the new approach mentioned about we can enable in default group
> also.
> 
> > 
> > > > > 4) It can't be pseudo-locked
> > > > 
> > > > Yes.
> > > > 
> > > > > 
> > > > > Would a potential use case involve putting *all* tasks into the PLZA group? That
> > > > > would avoid any additional context switch overhead as the PLZA MSR would never
> > > > > need to change.
> > > > 
> > > > Yes. That can be one use case.
> > > > 
> > > > > 
> > > > > If that is the case, maybe for the PLZA group we should allow user to
> > > > > do:
> > > > > 
> > > > > # echo '*' > tasks
> > 
> > Dedicating a resource group to "PLZA" seems restrictive while also adding many
> > complications since this designation makes resource group behave differently and
> > thus the files need to get extra "treatments" to handle this "PLZA" designation.
> > 
> > I am wondering if it will not be simpler to introduce just one new file, for example
> > "tasks_cpl0" in both CTRL_MON and MON groups. When user space writes a task ID to the
> > file it "enables" PLZA for this task and that group's CLOSID and RMID is the associated
> > task's "PLZA" CLOSID and RMID. This gives user space the flexibility to use the same
> > resource group to manage user space and kernel space allocations while also supporting
> > various monitoring use cases. This still supports the "dedicate a resource group to PLZA"
> > use case where user space can create a new resource group with certain allocations but the
> > "tasks" file will be empty and "tasks_cpl0" contains the tasks needing to run with
> > the resource group's allocations when in CPL0.
> 
> Yes. We should be able do that. We need both tasks_cpl0 and cpus_cpl0.
> 
> We need make sure only one group can configured in the system and not allow
> in other groups when it is already enabled.
> 
> Thanks
> Babu
> 
> > 
> > Reinette
> > 
> > [1] https://lore.kernel.org/lkml/aXpgragcLS2L8ROe@agluck-desk3/
> > 

-Tony