Re: [PATCH v6 11/18] fs/resctrl: Introduce kmode_cpus/kmode_cpus_list per rdtgroup

[Reinette Chatre]

Hi Babu,

On 10/16/26 2:33 PM, Moger, Babu wrote:
> Hi Reinette,
> 
> 
> On 10/15/2026 10:31 AM, Reinette Chatre wrote:
>> Hi Babu,
>>
>> On 10/1/26 8:10 AM, Babu Moger wrote:
>>> The RESCTRL_GLOBAL_ENABLE_PER_CPU kernel mode allows tasks to use different
>>> allocation and monitoring associations when transitioning from user mode to
>>
>> Could "different allocation and monitoring associations" just be "different
>> CLOSID and RMID" (in places where this is what it refers to)? Being specific
>> and consistent with terms would make this so much easier to understand.
> 
> I avoided using CLOSID and RMID terms in filesystem specific code. If you are ok with that then I will use these terms.

Why?

Internally resctrl filesystem has a CLOSID assigned to a control group, RMID
assigned to a monitor group. When a user assigns a resource group to the global
kernel mode the kernel mode is implicitly assigned a CLOSID and/or RMID. These are
all part of the resctrl filesystem design. What is the benefit to avoid these specific
terms when explaining the implementation details?

An important distinction is that in this feature the CLOSID and RMID values originate
from a CTRL_MON or MON group assigned by user space. Any architecture where there is a
dependency between CLOSID and RMID will already have accounted for that during the
creation of the resource group. This is something that should be clear from the context
when referring to CLOSID and RMID.

The resctrl fs code even uses CLOSID and RMID in the API used to interact with the
architecture:
	void resctrl_arch_configure_kmode_global(const struct cpumask *cpu_mask,
						 u32 closid, bool assign_ctrl,
						 u32 rmid, bool assign_mon,
						 bool enable);

The only place where we should avoid using CLOSID and RMID is in anything
exposed to user space since CLOSID and RMID has different meanings on different
architectures.

Reinette