Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)

[Moger, Babu]

Hi Dave,

On 4/24/24 09:16, Dave Martin wrote:
> On Tue, Apr 23, 2024 at 09:15:07PM -0700, Reinette Chatre wrote:
>>
>>
>> On 4/23/2024 5:37 AM, Dave Martin wrote:
>>> On Mon, Apr 22, 2024 at 03:44:26PM -0500, Moger, Babu wrote:
>>>> Hi Dave,
>>>>
>>>> On 4/22/24 11:34, Dave Martin wrote:
>>>>> Hi Babu,
>>>>>
>>>>> On Thu, Apr 04, 2024 at 03:02:45PM -0500, Moger, Babu wrote:
>>>>>> Hi Peter,
>>>>>>
>>>>>>
>>>>>> On 4/4/24 14:08, Peter Newman wrote:
>>>>>>> Hi Babu,
>>>>>>>
>>>>>>> On Thu, Mar 28, 2024 at 6:07 PM Babu Moger <babu.moger@xxxxxxx> wrote:
>>>>>>>>    The list follows the following format:
>>>>>>>>
>>>>>>>>        * Default CTRL_MON group:
>>>>>>>>                "//<domain_id>=<assignment_flags>"
>>>>>>>>
>>>>>>>>        * Non-default CTRL_MON group:
>>>>>>>>                "<CTRL_MON group>//<domain_id>=<assignment_flags>"
>>>>>>>>
>>>>>>>>        * Child MON group of default CTRL_MON group:
>>>>>>>>                "/<MON group>/<domain_id>=<assignment_flags>"
>>>>>>>>
>>>>>>>>        * Child MON group of non-default CTRL_MON group:
>>>>>>>>                "<CTRL_MON group>/<MON group>/<domain_id>=<assignment_flags>"
>>>>>>>>
>>>>>>>>        Assignment flags can be one of the following:
>>>>>>>>
>>>>>>>>         t  MBM total event is assigned
>>>>>>>>         l  MBM local event is assigned
>>>>>>>>         tl Both total and local MBM events are assigned
>>>>>>>>         _  None of the MBM events are assigned
>>>>>>>>
>>>>>>>>         Examples:
>>>>>>>>
>>>>>>>>         # cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>>>>>         non_defult_group//0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
>>>>>>>>         non_defult_group/non_default_mon1/0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
>>>>>>>>         //0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
>>>>>>>>         /default_mon1/0=tl;1=tl;2=tl;3=tl;4=tl;5=tl;6=tl;7=tl;
>>>>>>>>
>>>>>>>>         There are four groups and all the groups have local and total event assigned.
>>>>>>>>
>>>>>>>>         "//" - This is a default CONTROL MON group
>>>>>>>>
>>>>>>>>         "non_defult_group//" - This is non default CONTROL MON group
>>>>>>>>
>>>>>>>>         "/default_mon1/"  - This is Child MON group of the defult group
>>>>>>>>
>>>>>>>>         "non_defult_group/non_default_mon1/" - This is child MON group of the non default group
>>>>>>>>
>>>>>>>>         =tl means both total and local events are assigned.
>>>>>>>
>>>>>>> I recall there was supposed to be a way to perform the same update on
>>>>>>> all domains together so that it isn't tedious to not do per-domain
>>>>>>
>>>>>> Yes. Correct. Reinette suggested to have "no domains" means ALL the domains.
>>>>>
>>>>> Would "*" be more intuitive?
>>>>
>>>> We could. But I don't see the need for wildcard ("*") or ranges and
>>>> complexity that comes with that.
>>>
>>> For "*", I mean that this would just stand for "all cpus", not a generic
>>> string match; apologies if I didn't make that clear.
>>
>> (reading this by replacing "all cpus" with "all domains")
>>
>> This sounds reasonable to me. It may indeed make the parsing simpler by
>> not needing the ugly checks Babu mentioned in [1].

Sure. Will plan to address "all domains" (*) option in next revision.

>>
>> Reinette
>>
>> [1] https://lore.kernel.org/lkml/7ccd59b8-9fe3-4d1f-82f5-f33d96dbf5ac@xxxxxxx/
> 
> Ack, I meant "all domains", sorry!
> 
> Note, should we try to detect things like:
> 
> 	<resource>:0=fee;1=fie;*=foe;0=fum
> 
> ..?
> 
> Either we treat conflicting assignments as an error, or we do them all
> in the order specified, so that assignments on the right override those
> on the left (which is what the schemata parsing in ctrlmondata.c:
> parse_line() seems to do today if I understand the code correctly).
> 
> In the latter case,
> 
> 	<resource>:*=fee;1=fie
> 
> would set all nodes except 1 to "fee", and node 1 to "fie", which might
> be useful (or at least, convenient).
> 
> If we're worried about that being exposed as ABI and used by userspace,
> we might want to disallow it explicitly.
> 

Sure. Right now we are not planning to support domain specific
assignments. But, will plan to keep options open for future support.
-- 
Thanks
Babu Moger