Re: [PATCH v2 00/16] fs,x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem

[Reinette Chatre]

Hi Babu,

On 4/21/26 11:19 AM, Babu Moger wrote:
> On 4/21/26 12:35, Reinette Chatre wrote:
>> On 4/21/26 9:46 AM, Babu Moger wrote:
>>> On 4/21/26 11:15, Reinette Chatre wrote:
>>>> On 4/21/26 8:08 AM, Babu Moger wrote:


>>>>>
>>>>> # echo "global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/
>>>>>
>>>>> Why do we still need to keep the "inherit_ctrl_and_mon"?  By default all the groups in the system falls in this category it is not plza enabled group.

Here you question why "inherit_ctrl_and_mon" is needed ...

>>>>>
>>>>>
>>>>> System boots up with following options if PLZA is supported.
>>>>>
>>>>> # cat info/kernel_mode
>>>>>         global_assign_ctrl_assign_mon_per_cpu
>>>>>         global_assign_ctrl_inherit_mon_per_cpu
>>>>>
>>>>> No groups are associated with kernel mode at this point.
>>>>
>>>> To me it seems useful to be clear to user space on what the current mode is. If I understand correctly
>>>> above default scenario essentially means "inherit_ctrl_and_mon" but instead of adding it to this file
>>>> we will need to add documentation that describes to user space how this file should be interpreted.
>>>> It seems easier to me to just be clear via info/kernel_mode itself on what the current active mode is?
>>>>
>>>> I think something like below will be more intuitive and not need much additional
>>>> documentation to understand (I am just adding the "uninitialized" as an example to match text
>>>> printed in schemata file during pseudo-locking ... even if there is a group named "uninitialized"
>>>> the lack of "/" could be used to make it clear what this means?):
>>>>
>>>>      # cat info/kernel_mode
>>>>      [inherit_ctrl_and_mon]
>>>>      global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
>>>>      global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
>>>>

Above I share considerations when thinking whether to keep "inherit_ctrl_and_mon" or not ...

>>>
>>> Sounds ok to me.

... to which you seem to agree ...

>>>
>>>
>>>> I also think an interface like this would be simpler for user space to use as it (user space) switches
>>>> between PLZA capable and non-PLZA capable systems since user space need not associate existence of
>>>> the file with some kernel mode state in addition to actual content of the file when it does exist.


... more considerations from me when thinking whether to keep "inherit_ctrl_and_mon" or not ...

>>>>
>>>> I assumed that info/kernel_mode can just always be made visible and not depend on PLZA
>>>> capable hardware. This means that on Intel and Arm this file can show:
>>>>
>>>>      # cat info/kernel_mode
>>>>      [inherit_ctrl_and_mon]
>>>>
>>>
>>> Yes. Sure.

... to which you seem to agree ...

>>>
>>>
>>>> For Intel this is accurate and also for Arm if I interpret the Arm implementation correctly
>>>> (see mpam_thread_switch()) in  https://lore.kernel.org/lkml/20260313144617.3420416-7-ben.horgan@xxxxxxx/

... and even more considerations from me when thinking whether to keep "inherit_ctrl_and_mon" or not.

...

>>> There is one problem here. The mode "inherit_ctrl_and_mon" listing not consistent with others.
>>
>> It is difficult to predict what resctrl will be asked to support next. One possibility here is
>> to make it part of the original design that the first field is the "mode" and the following field
>> contains that mode's global properties of which there could be more than one. Above shows that
>> the two "global" modes have a single global property but we could just try to be safe with some
>> documentation that states there could be more.
>>
>> Consider for example some hypothetical future where the file looks like:
>>
>>     # cat info/kernel_mode
>>     inherit_ctrl_and_mon:some_unique_capability=true
>>     global_assign_ctrl_assign_mon_per_cpu:group=uninitialized;other_property=val
>>     [global_assign_ctrl_assign_mon_per_cpu:group=ctrl1/mon1/]
>>
>> To leave room for growth the file could start out by, for example, appending ":"
>> to "inherit_ctrl_and_mon" to indicate that there are no known properties yet?  Something like
>> below. Would this be more consistent with the others?
> 
> To me, it might be clearer to simply document what the default mode is when kernel mode is not enabled, and omit "inherit_ctrl_and_mon" from the display.

... and now you question again why "inherit_ctrl_and_mon" should be included in display without
a motivation why and without addressing any of the previous considerations motivating its
inclusion. How can I respond when you clearly ignore my response to the previous time you asked
this question?

My previous comments are still valid. You mention that "it might be clearer to simply document what
the default mode is when kernel mode is not enabled". To me there is not really a "disabled" kernel mode
since kernel work done on behalf of a task needs to be done with *some* allocation - kernel mode is not
"disabled". Why should resctrl not make it clear what this behavior is? Adding another consideration to
the list ... what if resctrl needs to support some other "default" mode in the future? How can a user
know that not having an active mode means one or the other "default" mode?

If you feel that "inherit_ctrl_and_mon" should be omitted then please motivate why and also address why
the considerations I mentioned are not valid.

Reinette