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

[Moger, Babu]

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