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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d524bc5d-b81f-4c99-960f-3087f0e2760c@amd.com>
Date: Wed, 24 Apr 2024 14:10:31 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Dave Martin <Dave.Martin@....com>,
 Reinette Chatre <reinette.chatre@...el.com>
Cc: Peter Newman <peternewman@...gle.com>, corbet@....net,
 fenghua.yu@...el.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 paulmck@...nel.org, rdunlap@...radead.org, tj@...nel.org,
 peterz@...radead.org, yanjiewtw@...il.com, kim.phillips@....com,
 lukas.bulwahn@...il.com, seanjc@...gle.com, jmattson@...gle.com,
 leitao@...ian.org, jpoimboe@...nel.org, rick.p.edgecombe@...el.com,
 kirill.shutemov@...ux.intel.com, jithu.joseph@...el.com,
 kai.huang@...el.com, kan.liang@...ux.intel.com,
 daniel.sneddon@...ux.intel.com, pbonzini@...hat.com, sandipan.das@....com,
 ilpo.jarvinen@...ux.intel.com, maciej.wieczor-retman@...el.com,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, eranian@...gle.com,
 james.morse@....com
Subject: Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable
 Bandwidth Monitoring Counters (ABMC)

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