Re: [PATCH v13 21/27] x86/resctrl: Introduce mbm_assign_on_mkdir to configure assignments

["Moger, Babu" <bmoger@amd.com>]

Hi Reinette,

On 5/30/2025 3:54 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 5/29/25 4:03 PM, Moger, Babu wrote:
>> Hi Reinette,
>>
>> On 5/22/2025 11:48 PM, Reinette Chatre wrote:
>>> Hi Babu,
>>>
>>> On 5/15/25 3:52 PM, Babu Moger wrote:
>>>> The mbm_cntr_assign mode provides an option to the user to assign a
>>>> counter to an RMID, event pair and monitor the bandwidth as long as
>>>> the counter is assigned.
>>>>
>>>> Introduce a configuration option to automatically assign counter IDs
>>>
>>> "assign counter IDs" -> "assign counter IDs to <what?>"
>>
>> "Introduce a configuration option to automatically assign counter IDs to to an RMID, event pair when a resctrl group is created, provided the counter IDs are available."
> 
> Stating that "counter IDs" (plural) are assigned to "an RMID, event pair" (singular)
> can be confusing.
> 
> How about something like (please feel free to improve):
> "Introduce a user-configurable option that determines if a counter will automatically
> be assigned to an RMID, event pair when its associated monitor group is created via mkdir."

Sure.

> 
> 
>>
>>>
>>>> when a resctrl group is created, provided the counters are available.
>>>> By default, this option is enabled at boot.
>>>>
>>>> Suggested-by: Peter Newman <peternewman@google.com>
>>>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>>>> ---
>>>> v13: Added Suggested-by tag.
>>>>        Resolved conflicts caused by the recent FS/ARCH code restructure.
>>>>        The rdtgroup.c/monitor.c file has now been split between the FS and ARCH directories.
>>>>
>>>> v12: New patch. Added after the discussion on the list.
>>>>        https://lore.kernel.org/lkml/CALPaoCh8siZKjL_3yvOYGL4cF_n_38KpUFgHVGbQ86nD+Q2_SA@mail.gmail.com/
>>>> ---
>>>>    Documentation/filesystems/resctrl.rst | 10 ++++++
>>>>    fs/resctrl/monitor.c                  |  2 ++
>>>>    fs/resctrl/rdtgroup.c                 | 44 +++++++++++++++++++++++++--
>>>>    include/linux/resctrl.h               |  2 ++
>>>>    4 files changed, 56 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
>>>> index 9923276826db..356f1f918a86 100644
>>>> --- a/Documentation/filesystems/resctrl.rst
>>>> +++ b/Documentation/filesystems/resctrl.rst
>>>> @@ -348,6 +348,16 @@ with the following files:
>>>>          # cat /sys/fs/resctrl/info/L3_MON/counter_configs/mbm_total_bytes/event_filter
>>>>           local_reads, local_non_temporal_writes
>>>>    +"mbm_assign_on_mkdir":
>>>> +    Automatically assign the monitoring counters on resctrl group creation
>>>
>>> assign the monitoring counters to what?
>>
>> "Automatically assign counter IDs to an RMID, event pair on resctrl group creation if the counter IDs are available. It is enabled by default on boot and users can disable by writing to the interface."
> 
> Same here, please take care with the plural/singular usage.

Sure.

> 
>>
>>>> +    if the counters are available. It is enabled by default on boot and users
>>>> +    can disable by writing to the interface.
>>>> +    ::
>>>> +
>>>> +      # echo 0 > /sys/fs/resctrl/info/L3_MON/mbm_assign_on_mkdir
>>>> +      # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_on_mkdir
>>>> +      0
>>>
>>> Please be explicit in docs what possible values are and what they mean.
>>
>> Sure. I can print "enabled" or "disabled".
> 
> I am not requesting a change in user interface self but instead clear documentation about
> what the input/output values mean. Even if the interface changes to "enabled"/"disabled"
> I assume the interface will still accept boolean values? Compare to the "sparse_masks"
> documentation on how the possible values are explicitly documented.
> 

ok. Will look into that.

> ...
> 
>>>> +static ssize_t resctrl_mbm_assign_on_mkdir_write(struct kernfs_open_file *of,
>>>> +                         char *buf, size_t nbytes, loff_t off)
>>>> +{
>>>> +    struct rdt_resource *r = rdt_kn_parent_priv(of->kn);
>>>> +    bool value;
>>>> +    int ret;
>>>> +
>>>> +    ret = kstrtobool(buf, &value);
>>>> +    if (ret)
>>>> +        return ret;
>>>> +
>>>> +    cpus_read_lock();
>>>
>>> not traversing the domain list so hotplug lock not needed.
>>
>> ok. Sure.
>>
>>>
>>>> +    mutex_lock(&rdtgroup_mutex);
>>>
>>> rdtgroup_mutex seems only needed because the message buffer is cleared below, and this is why it
>>> is not required in the show()?
>>
>> Hmm. I didnt think about that. Do you think it is required?
> 
> It is certainly required to be able to call rdt_last_cmd_clear() and since it then
> covers mbm_assign_on_mkdir I would prefer symmetry in consistently acquiring
> rdtgroup_mutex on both read and write while resctrl is mounted. Note that
> there is also other read usage on resctrl mount that is done with
> mutex held. Having the mutex acquired consistently will help to keep things
> simple.
> 

Sure. will do.

> ...
> 
>>>> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
>>>> index cd24d1577e0a..d6435abdde7b 100644
>>>> --- a/include/linux/resctrl.h
>>>> +++ b/include/linux/resctrl.h
>>>> @@ -278,6 +278,7 @@ enum resctrl_schema_fmt {
>>>>     *            monitoring events can be configured.
>>>>     * @num_mbm_cntrs:    Number of assignable monitoring counters
>>>>     * @mbm_cntr_assignable:Is system capable of supporting monitor assignment?
>>>> + * @mbm_assign_on_mkdir:Auto enable monitor assignment on mkdir?
>>>
>>> How is "monitor assignment" different from "counter assignment"?
>>
>> I should be:
>>
>> "Auto enable counter ID assignment on mkdir"
> 
> hmmm ... I do not think this is about "Auto enable".
> How about something like "Automatic counter assignment during monitor group create via mkdir?"
> or "True if counters should automatically be assigned to MBM events of monitor groups
> created via mkdir."

Sure. Thanks
Babu