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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <004dcaeb-30ae-4b27-895a-4025a670fcbf@amd.com>
Date: Mon, 22 Apr 2024 15:44:26 -0500
From: "Moger, Babu" <babu.moger@....com>
To: Dave Martin <Dave.Martin@....com>
Cc: Peter Newman <peternewman@...gle.com>, corbet@....net,
 fenghua.yu@...el.com, reinette.chatre@...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/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.

Even in schemata processing we don't use the wildcard or ranges and also
there is no mention of that in documentation.
https://www.kernel.org/doc/Documentation/x86/resctrl.rst

Domains(or nodes) are processed one by one. Some examples.

 # cat schemata
    SMBA:0=2048;1=2048;2=2048;3=2048
      MB:0=2048;1=2048;2=2048;3=2048
      L3:0=ffff;1=ffff;2=ffff;3=ffff

  # echo "SMBA:1=64" > schemata
  # cat schemata
    SMBA:0=2048;1=  64;2=2048;3=2048
      MB:0=2048;1=2048;2=2048;3=2048
      L3:0=ffff;1=ffff;2=ffff;3=ffff



> 
> Whatever is done here to describe the "wildcard node", would it be worth
> having the node field parse the same way in the "schemata" files?
> 
> Is there any merit in having range match expressions, e.g. something like
> 
> 	0-3,8-11=foo;4-7,12-*=bar
> 
> (The latter is obvious feature creep though, so a real use case for this
> would be needed to justify it.  I don't have one right now...)
> 
> [...]
> 
> Cheers
> ---Dave

-- 
Thanks
Babu Moger