Re: [RESEND PATCH v4 04/15] fs/resctrl: Introduce kernel mode (kmode) data structures

[Reinette Chatre]

Hi Babu,

On 8/12/26 12:58 PM, Moger, Babu wrote:
> On 8/10/2026 10:03 PM, Reinette Chatre wrote:
>> On 7/7/26 2:50 PM, Babu Moger wrote:

>>> can report what is active or what the platform supports.
>>>
>>> Introduce enum resctrl_kernel_mode:
>>>    - INHERIT_CTRL_AND_MON: Kernel work inherits allocation and monitoring
>>>      from the user task (current behavior).
>>
>> The issue with this "combination" mode becomes obvious in patch 7. I also
>> see that sashiko hinted at this issue but I am not able to see from your response
>> what the plan is to address this. As highlighted by patch 7 and sashiko the
>> "allocation" and "monitoring" features of a system are independent - a system
>> need not support/enable both. This should be easy to reproduce by, for example,
>> booting a system with needed rdt= options disabling allocation or monitoring
>> features.
>>
>> I think it will be unexpected to a user on an allocation-only system to
>> see interface like:
>>
>>   # cat info/kernel_mode
>>    [inherit_ctrl_and_mon]
>>    global_assign_ctrl_inherit_mon_per_cpu:group=uninitialized
>>    global_assign_ctrl_assign_mon_per_cpu:group=uninitialized
>>
>> Should it not rather be, for example:
>>   # cat info/kernel_mode
>>    [inherit_ctrl]
>>    global_assign_ctrl_per_cpu:group=uninitialized
>>
>> Similarly the user input would not need to provide a monitor group when system
>> only supports allocation.
> 
> Ok. Yea. We need to separate control and monitor separately.
> 
> 
> How about something like this?
> 
>  # cat info/kernel_mode
>    [ctrl=inherit,mon=inherit]
>    ctrl=assign,mon=inherit:group=uninitialized
>    ctrl=assign,mon=assign:group=uninitialized
>    ctrl=inherit,mon=assign:group=uninitialized
> 
> If allocation(ctrl) is only supported.
> 
>  # cat info/kernel_mode
>    [ctrl=inherit]
>    ctrl=assign:group=uninitialized
> 
> If monitor (mon) is only supported.
> 
>  # cat info/kernel_mode
>    [mon=inherit]
>    mon=assign:group=uninitialized
> 
> 

Please always keep in mind all the requirements and use cases we learned about 
during and after RFC v1 of this work.

For example, we already know that "per group" assignment is something resctrl
needs to be ready for. Consider the example in
https://lore.kernel.org/lkml/aYyxAPdTFejzsE42@xxxxxxxxxxxxxxx/

There may even be "per task" assignment in the future.

Constraining this feature to PLZA will make it harder to enable the capabilities
that we know resctrl need to support in the future.

This is how we originally landed on the "global" assignment distinction
(https://lore.kernel.org/lkml/2ab556af-095b-422b-9396-f845c6fd0342@xxxxxxxxx/)
"global assignment" should be kept or replaced with a solution that continues to
prepare resctrl for these other capabilities.

I am not able to see how resctrl could support "per group" assignment with the
interface you propose above. If I am missing this, please highlight the solution.

resctrl may need to explicitly split kernel mode from kernel mode properties. For
example, below shows an "assign_global_enable_per_cpu" as the kernel mode, now with three
properties: 
- "ctrl" - could be "assign" or "inherit"
- "mon" - could be "assign" or "inherit"
- "group" - required if "ctrl" or "mon" is set to "assign"

   # cat info/kernel_mode
   [inherit]
   assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized

When resctrl needs to support "per-group" assignment "kernel_mode" could contain
below with supporting documentation noting which per-resource group files will
appear when "assign_per_group" is selected that user space can use to manage
the assignments.

   # cat info/kernel_mode
   [inherit]
   assign_per_group

I am not asking you to go and implement this. This was just the first idea that
came to ming that I am using to highlight that any new proposal needs to keep
previous discussions in mind.

Reinette