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

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

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.

> 
> 
> "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.

> 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?

> 
>   - 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.

Reinette