Re: [PATCH v6 04/18] fs/resctrl: Introduce kernel mode enum

[Babu Moger <babu.moger@amd.com>]

Hi Reinette,

On 10/21/26 10:58, Reinette Chatre wrote:
> Hi Babu,
> 
> On 10/21/26 6:58 AM, Babu Moger wrote:
>> On 10/19/26 11:17, Reinette Chatre wrote:
>>> On 10/15/26 4:09 PM, Babu Moger wrote:
>>>> On 10/15/26 09:44, Reinette Chatre wrote:
>>>>> On 10/1/26 8:10 AM, Babu Moger wrote:
>>>>>> Kernel mode work can use different allocation and monitoring associations
>>>>>
>>>>> Here I think "different allocation and monitoring associations" means
>>>>> different CLOSID/RMID, while other places "different allocation and monitoring
>>>>> associations" means different MSR_IA32_PQR_PLZA_ASSOC.closid_en and
>>>>> MSR_IA32_PQR_PLZA_ASSOC.rmid_en?
>>>>
>>>> That is correct. Hope text here is fine.
>>>>
>>> I had to guess. This is the same topic as being discussed in patch #3. Could you
>>> please add clear definitions to eliminate the need for guessing?
>>>
>>>
>> Ack, rephrased the changelog to use CLOSID and RMID terminology to
>> avoid the ambiguity around "allocation and monitoring associations".
>> If you agree, we can use CLOSID and RMID consistently throughout the
>> series.
> 
> I agree, with emphasis on consistently.
> 

Ack.

>>
>>
>> "fs/resctrl: Introduce kernel mode enum
>>
>> Kernel mode operation enables a CPU to use a different CLOSID and/or
>> RMID when executing in kernel mode than those used in user mode.
> 
> Please take care to distinguish between the "kernel mode" that defines the
> policy here and "kernel work" that is what the policy governs. At this time
> this series even conflates the two in some places ("kernel mode work").
> 
>>
>> Architectures need a common set of kernel mode definitions so resctrl
> 
> It is resctrl filesystem that needs the common vocabulary.

Ack.

> 
>> can report supported modes and indicate which mode is active.
>>
>> Introduce enum resctrl_kernel_mode:
>>
>>    - RESCTRL_INHERIT_USER: Kernel mode work inherits the CLOSID and/or
>>      RMID of the user task.
> 
> This does not look right, it inherits CLOSID *and* RMID, unconditionally, no?

Yes.
> 
>>
>>    - RESCTRL_GLOBAL_ENABLE_PER_CPU: Kernel mode work uses a single
>>      global CLOSID and/or RMID association shared by all userspace
>>      tasks. The mode can be enabled or disabled on a per-CPU basis.
> 
> "shared by all user space tasks" is not right? The CLOSID/RMID come from
> the backing CTRL_MON or MON group, so they are shared only with the tasks
> assigned to that group (possibly even none).
> 
> Below is a suggestion that aims to address the comments. Please do not just
> copy&paste without verifying it for accuracy and that it matches the terms you decided
> to stick with.
> 
> 
> 	Kernel work need not use the CLOSID and RMID of the user task on
> 	whose behalf it runs. On x86, Privilege Level Zero Association (PLZA)
> 	enables a CPU to use a different CLOSID and/or RMID while executing at
> 	privilege level zero.
> 
> 	resctrl needs common definitions of how kernel work is managed so that
> 	architectures can advertise the kernel modes they support and user space
> 	can query them and select the one to use.
> 
> 	Introduce enum resctrl_kernel_mode:
> 
> 	  - RESCTRL_INHERIT_USER: Kernel work uses the CLOSID and RMID of the
> 	    user task.
> 
> 	  - RESCTRL_GLOBAL_ENABLE_PER_CPU: All kernel work uses the CLOSID and/or
> 	    RMID of a single resource group, which may also have user tasks
> 	    assigned to it. The mode can be enabled or disabled per CPU; on a CPU
> 	    where it is disabled, kernel work inherits the user task's CLOSID and RMID.
> 
Looks good.
Thanks
Babu