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

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Babu,

On 8/13/26 8:17 AM, Babu Moger wrote:
> On 8/12/26 18:28, Reinette Chatre wrote:

>> 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@e134344.arm.com/
>>
>> There may even be "per task" assignment in the future.
> 
> Yes. That is correct.
> 
>>
>> 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@intel.com/)
>> "global assignment" should be kept or replaced with a solution that continues to
>> prepare resctrl for these other capabilities.
> 
> Yes. Makes sense.
> 
>>
>> 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"
> 
> ok.
> 
> 
>>
>>     # cat info/kernel_mode
>>     [inherit]
>>     assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=uninitialized
> 
> Shouldn't this be like below when default is inherit?
> 
> # cat info/kernel_mode
> [inherit]
> assign_global_enable_per_cpu
> 

I think it will be useful to let the interface:
 (a) show to user space which properties are available for each supported mode, and
 (b) show user space what the default value of those properties will be if they
     are not set when the associated mode is enabled.

To (b), since the default resource group is used as default when the group
is not provided it may be better to use "//" (or just "/", depending on system
supporting just one of allocation or monitoring) instead of "uninitialized".

> 
> When the default changes to assign_global_enable_per_cpu:
> 
> # cat info/kernel_mode
> inherit [assign_global_enable_per_cpu:ctrl=assign;mon=assign;group=ctrl_mon1//]
> 
> Display the second mode with properties only when group is associated with it?

Please consider this from user space side. The user needs to enable the mode.
How will the user know which properties are available and what the defaults are?

> 
> # cat info/kernel_mode
> inherit
> [assign_global_enable_per_cpu:mon=assign;group=ctrl1/mon1/]
> 
> 
>>
>> 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 know it is future. What could be difference between assign_global_enable_per_cpu and assign_per_group?
> 
Please see https://lore.kernel.org/lkml/aYyxAPdTFejzsE42@e134344.arm.com/ 

Essentially, in the "assign_per_group" mode the user space resource allocation and monitoring
dictates what kernel mode resource allocation and monitoring to use. This cannot support the use
case where user wants to monitor all user space and kernel work together in the same monitoring group
though, but that is a difficult use case for MPAM anyway and this can be solved by summing monitoring
data of user space and kernel groups.

Reinette