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

[Babu Moger]

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)

Also, you mentioned about rftype::create_hidden in
https://lore.kernel.org/lkml/0126a5e5-48cf-416f-a21b-c231a703c18b@xxxxxxxxx/

Can you please clarify on this?

> > These expose rdtgrp->kmode_cpu_mask in both bitmap and range-list formats,
> > consistent with the existing cpus and cpus_list interfaces.
> >
> > Signed-off-by: Babu Moger <babu.moger@xxxxxxx>
> > ---
>
>
>
> > diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
> > index 178126bb2da5..12db6933bc54 100644
> > --- a/fs/resctrl/internal.h
> > +++ b/fs/resctrl/internal.h
> > @@ -216,6 +216,8 @@ struct mongroup {
> >    * @mon:			mongroup related data
> >    * @mode:			mode of resource group
> >    * @mba_mbps_event:		input monitoring event id when mba_sc is enabled
> > + * @kmode:			true if this group is bound to a kernel-mode policy
> > + * @kmode_cpu_mask:		CPU scope for this group's kernel-mode binding
>
> "CPU scope" could be interpreted in various ways here. Could it be more specific to
> say something like "CPUs on which kernel mode is active"?
>
> >    * @plr:			pseudo-locked region
> >    */
> >   struct rdtgroup {
> > @@ -229,6 +231,8 @@ struct rdtgroup {
> >   	struct mongroup			mon;
> >   	enum rdtgrp_mode		mode;
> >   	enum resctrl_event_id		mba_mbps_event;
> > +	bool				kmode;
> > +	struct cpumask			kmode_cpu_mask;
> >   	struct pseudo_lock_region	*plr;
> >   };
> >   
> > diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> > index 346aa4df62a4..0d5c94169d03 100644
> > --- a/fs/resctrl/rdtgroup.c
> > +++ b/fs/resctrl/rdtgroup.c
> > @@ -392,6 +392,37 @@ static int rdtgroup_cpus_show(struct kernfs_open_file *of,
> >   	return ret;
> >   }
> >   
> > +/*
> > + * Display per-rdtgroup CPU bindings for kernel-mode enabled groups.
> > + * Supports both "kmode_cpus" (bitmap format) and "kmode_cpus_list"
> > + * (range list format); the output format is selected accordingly.
> > + *
> > + * Returns -ENOENT if the group has been deleted, and -ENODEV for
> > + * pseudo-locked groups, which cannot host a kernel-mode binding.
> > + */
> > +static int rdtgroup_kmode_cpus_show(struct kernfs_open_file *of,
> > +				    struct seq_file *s, void *v)
> > +{
> > +	struct rdtgroup *rdtgrp;
> > +	int ret = 0;
> > +
> > +	rdtgrp = rdtgroup_kn_lock_live(of->kn);
> > +
> > +	if (rdtgrp) {
> > +		if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED) {
> > +			ret = -ENODEV;
>
> sashiko also pointed something related out but it is not clear to me how the
> different group modes are planned to be accommodated. I think it should be possible
> to avoid sprinkling these mode checks into user space interactions if it is
> made explicit that (a) at the time a group is assigned to a kernel mode that
> group is required to be "shareable", and (b) it is not allowed to change
> the mode of a group that is assigned to a kernel mode.

Sure. We can add there checks.

> Apart from that I do not think a test like this is sufficient to capture the
> various scenarios that may occur. For example, while waiting for the lock
> the group assigned to the kernel mode could have been re-assigned.
> Could a test on rdtgrp->kmode be more robust?

Basically, I need to check for rdtgrp->kmode  here. Sure.

thanks
Babu