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

[Ben Horgan]

Hi Reinette,

On 2/19/26 18:14, Reinette Chatre wrote:
> Hi Ben,
> 
> On 2/19/26 2:21 AM, Ben Horgan wrote:
>> On 2/17/26 18:51, Reinette Chatre wrote:
>>> On 2/16/26 7:18 AM, Ben Horgan wrote:
>>>> On Thu, Feb 12, 2026 at 10:37:21AM -0800, Reinette Chatre wrote:
>>>>> On 2/12/26 5:55 AM, Ben Horgan wrote:
>>>>>> On Wed, Feb 11, 2026 at 02:22:55PM -0800, Reinette Chatre wrote:
>>>>>>> On 2/11/26 8:40 AM, Ben Horgan wrote:
>>>>>>>> On Tue, Feb 10, 2026 at 10:04:48AM -0800, Reinette Chatre wrote:
>>>
>>>>>>>>> It looks like MPAM has a few more capabilities here and the Arm levels are numbered differently
>>>>>>>>> with EL0 meaning user space. We should thus aim to keep things as generic as possible. For example,
>>>>>>>>> instead of CPL0 using something like "kernel" or ... ?
>>>>>>>>
>>>>>>>> Yes, PLZA does open up more possibilities for MPAM usage.  I've talked to James
>>>>>>>> internally and here are a few thoughts.
>>>>>>>>
>>>>>>>> If the user case is just that an option run all tasks with the same closid/rmid
>>>>>>>> (partid/pmg) configuration when they are running in the kernel then I'd favour a
>>>>>>>> mount option. The resctrl filesytem interface doesn't need to change and
>>>>>>>
>>>>>>> I view mount options as an interface of last resort. Why would a mount option be needed
>>>>>>> in this case? The existence of the file used to configure the feature seems sufficient?
>>>>>>
>>>>>> If we are taking away a closid from the user then the number of CTRL_MON groups
>>>>>> that can be created changes. It seems reasonable for user-space to expect
>>>>>> num_closid to be a fixed value.
>>>>>
>>>>> I do you see why we need to take away a CLOSID from the user. Consider a user space that
>>>>
>>>> Yes, just slightly simpler to take away a CLOSID but could just go with the
>>>> default CLOSID is also used for the kernel. I would be ok with a file saying the
>>>> mode, like the mbm_event file does for counter assignment. It slightly misleading
>>>> that a configuration file is under info but necessary as we don't have another
>>>> location global to the resctrl mount.
>>>
>>> Indeed, the "info" directory has evolved more into a "config" directory.
>>>
>>>>> runs with just two resource groups, for example, "high priority" and "low priority", it seems
>>>>> reasonable to make it possible to let the "low priority" tasks run with "high priority"
>>>>> allocations when in kernel space without needing to dedicate a new CLOSID? More reasonable
>>>>> when only considering memory bandwidth allocation though.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Also ...
>>>>>>>
>>>>>>> I do not think resctrl should unnecessarily place constraints on what the hardware
>>>>>>> features are capable of. As I understand, both PLZA and MPAM supports use case where
>>>>>>> tasks may use different CLOSID/RMID (PARTID/PMG) when running in the kernel. Limiting
>>>>>>> this to only one CLOSID/PARTID seems like an unmotivated constraint to me at the moment.
>>>>>>> This may be because I am not familiar with all the requirements here so please do
>>>>>>> help with insight on how the hardware feature is intended to be used as it relates
>>>>>>> to its design.
>>>>>>>
>>>>>>> We have to be very careful when constraining a feature this much  If resctrl does something
>>>>>>> like this it essentially restricts what users could do forever.
>>>>>>
>>>>>> Indeed, we don't want to unnecessarily restrict ourselves here. I was hoping a
>>>>>> fixed kernel CLOSID/RMID configuration option might just give all we need for
>>>>>> usecases we know we have and be minimally intrusive enough to not preclude a
>>>>>> more featureful PLZA later when new usecases come about.
>>>>>
>>>>> Having ability to grow features would be ideal. I do not see how a fixed kernel CLOSID/RMID
>>>>> configuration leaves room to build on top though. Could you please elaborate?
>>>>
>>>> If we initially go with a single new configuration file, e.g. kernel_mode, which
>>>> could be "match_user" or "use_root, this would be the only initial change to the
>>>> interface needed. If more usecases present themselves a new mode could be added,
>>>> e.g. "configurable", and an interface to actually change the rmid/closid for the
>>>> kernel could be added.
>>>
>>> Something like this could be a base to work from. I think only the two ("match_user" and
>>> "use_root") are a bit limiting for even the initial implementation though.
>>> As I understand, "use_root" implies using the allocations of the default group but
>>> does not indicate what MON group (which RMID/PMG) should be used to monitor the
>>> work done in kernel space. A way to specify the actual group may be needed?
>>
>> Yeah, I'm not sure that flexibility is strictly necessary but will make
>> the interface easier to use.
> 
> I find your proposal to be a good foundation to build on. I am in process of trying out
> some ideas around it for consideration and comparison to other ideas.
> 
> ...
> 
>>>>> existing "tasks" file does but only supports the same CLOSID/RMID for both user
>>>>> space and kernel space. To support the new hardware features where the CLOSID/RMID
>>>>> can be different we cannot just change "tasks" interface and would need to keep it
>>>>> backward compatible. So far I assumed that it would be ok for the "tasks" file
>>>>> to essentially get new meaning as the CLOSID/RMID for just user space work, which 
>>>>> seems to require a second file for kernel space as a consequence? So far I have
>>>>> not seen an option that does not change meaning of the "tasks" file.
>>>>
>>>> Would it make sense to have some new type of entries in the tasks file,
>>>> e.g. k_ctrl_<pid>, k_mon_<pid> to say, in the kernel, use the closid of this
>>>> CTRL_MON for this task pid or use the rmid of this CTRL_MON/MON group for this task
>>>> pid? We would still probably need separate files for the cpu configuration.
>>>
>>> I am obligated to nack such a change to the tasks file since it would impact any
>>> existing user space parsing of this file.
>>>
>>
>> Good to know. Do you consider the format of the tasks file fully fixed?
> 
> At this point I believe it is fully fixed, yes. For this we need to consider both
> how it is documented to be used and how it is used. For the former we of course have
> Documentation/filesystems/resctrl.rst but for the latter it becomes difficult.
> 
> On the documentation side I also find existing documentation to be specific in how
> "tasks" file should be interpreted: "Reading this file shows the list of all tasks
> that belong to this group.". I do not find there to be a lot of room for changing
> interpretation here.
> 
> An interface change as you suggest is reasonable for a file that is consumed by a
> human - somebody can read the file and immediately notice the change and it may even
> be intuitive. We know that there is a lot of tooling built around resctrl fs though
> so we should evaluate impact of any interface changes on such automation. Not all of this
> tooling is public so this is where things become difficult to predict the impact so
> we tend to be conservative in assumptions here.
> 
> There is one open source resctrl fs tool, the "pqos" utility [1], that is getting a lot of
> usage and it could be a predictor (albeit not decider) of such interface change impact.
> A peek at how it parses the "tasks" file confirms that it only expects a number, see
> resctrl_alloc_task_read() at https://github.com/intel/intel-cmt-cat/blob/master/lib/resctrl_alloc.c#L437 
> I thus expect that a user running pqos on a kernel that contains such a change to the
> "tasks" file will fail which confirms changing syntax of "tasks" file should be avoided.

Thanks for this information. This will help when trying to think how we
can add any further features.

> 
> Reinette
> 
> [1] https://github.com/intel/intel-cmt-cat
> 
> 


Thanks,

Ben