Re: [RESEND PATCH v4 09/15] fs/resctrl: Introduce kmode_cpus/kmode_cpus_list per rdtgroup

Hi Reinette,

On 8/13/2026 3:49 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 8/13/26 12:27 PM, Babu Moger wrote:
>> On 8/13/26 13:19, Reinette Chatre wrote:
>>> On 8/13/26 10:57 AM, Babu Moger wrote:
>>>> Hi Reinette,
>>>>
>>>> On 8/10/26 22:20, Reinette Chatre wrote:
>>>>> Hi Babu,
>>>>>
>>>>> On 7/7/26 2:50 PM, Babu Moger wrote:
>>>>>> Kernel-mode resctrl policies allow kernel work to be associated with a
>>>>>> specific rdtgroup, optionally restricted to a subset of online CPUs.
>>>>>>
>>>>>> While user space can query the active kernel-mode policy and its associated
>>>>>> rdtgroup through info/kernel_mode, it currently lacks visibility into the
>>>>>> CPU scope of that binding.
>>>>>>
>>>>>> Introduce read-only kmode_cpus and kmode_cpus_list files for each rdtgroup.
>>>>>
>>>>> I think it will be easier to follow if this is deferred to not create these
>>>>> files in all resource groups by default. Instead, at the time they are
>>>>> created it should be obvious that they will only be visible in resource group
>>>>> associated with the active kernel mode.
>>>>
>>>> I am not clear on this comment. Do you mean create these files when user associates the group to kernel mode? (during rdtgroup_config_kmode)
>>>
>>> No. As this changelog states it creates these files in all resource groups. This
>>> is a confusing thing to do at this point in the series since these files are not
>>> expected to be present/visible in all resource groups, only in a resource group that
>>> is assigned to the "global" kernel mode. This commit mentions nothing about this
>>> usage and thus from reader perspective does not seem like the right thing to do here.
>>
>> Ok. Got it. Commit message is not clear.
> 
> This is not just about the commit message being unclear. This commit adds functionality
> that patches that follow undo. I find this strategy unnecessary even if the commit message
> is changed to reflect this. I find having the functionality as intended from the
> beginning easier to follow.

Ok. Sure.

This code will also be revised to accommodate the addition of hidden 
file creation functionality.

Thanks
Babu