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

[Babu Moger <babu.moger@amd.com>]

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@intel.com/

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@amd.com>
>> ---
> 
> 
> 
>> 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