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

[Moger, Babu]

Hi Reinette,

On 2/13/2026 6:10 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 2/13/26 8:37 AM, 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.
>
> ah - this is a significant part that I missed. Since this is a per-CPU register it seems
> to have the ability for expanded use in the future where different CLOSID and RMID may be
> written to it? Is PLZA leaving room for such future enhancement or does the spec contain
> the text that state "The values in the MSR_IA32_PQR_PLZA_ASSOC register (RMID, RMID_EN,
> CLOSID, CLOSID_EN) must be identical across all logical processors."? That is, "forever
> and always"?

It should be identical across all the logical processors.  Don't know 
about the future generations. Its better to keep that option open.

> If I understand correctly MPAM could have different PARTID and PMG for kernel use so we
> need to consider these different architectural behaviors.

oh ok.


> > 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.
> >
> > > 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.
>
> As I understand this means that only one group can have content in its
> tasks_cpl0/tasks_kernel file. There should not be any special handling for
> the remaining files of the resource group since the resource group is not
> dedicated to kernel work and can be used as a user space resource group also.
> If user space wants to create a dedicated kernel resource group there can be
> a new resource group with an empty tasks file.

Correct.

> hmmm ... but if user space writes a task ID to a tasks_cpl0/tasks_kernel file then
> resctrl would need to create new syntax to remove that task ID.


I'm not sure I fully understand this, so let me restate the sequence:

Example 1: Regular group

# mkdir /sys/fs/resctrl/test1

This creates a normal resctrl group.


# echo 1 > /sys/fs/resctrl/test1/tasks

The group is still a normal group at this point.


# echo 1 > /sys/fs/resctrl/tasks_cpl0

This converts the group into a PLZA group (task’s tsk->plza field 
becomes 1). This works as a regular group because both user and kernel 
CLOSIDs are same.


Now create another group:

# mkdir /sys/fs/resctrl/test2

# echo 2 > /sys/fs/resctrl/tasks_cpl0

On AMD systems, this should fail with an error like: “Group test1 is 
already configured as a PLZA group”, because only one PLZA group is allowed.

Now remove task 1 from the test1 group:

# echo "" > /sys/fs/resctrl/tasks_cpl0

This resets the group back to a regular group.


Now try again to make test2 a PLZA group:
# echo 2 > /sys/fs/resctrl/tasks_cpl0

This should now succeed.

It makes more sense to have a dedicated group for plza in case of AMD. 
This option also allows to have a mix of both in one group.

Thanks
Babu