Received-SPF: pass (google.com: domain of linux-kernel+bounces-154005-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <004dcaeb-30ae-4b27-895a-4025a670fcbf@amd.com>
Date: Mon, 22 Apr 2024 15:44:26 -0500
User-Agent: Mozilla Thunderbird
Reply-To: babu.moger@amd.com
Subject: Re: [RFC PATCH v3 00/17] x86/resctrl : Support AMD Assignable
 Bandwidth Monitoring Counters (ABMC)
To: Dave Martin <Dave.Martin@arm.com>
Cc: Peter Newman <peternewman@google.com>, corbet@lwn.net,
 fenghua.yu@intel.com, reinette.chatre@intel.com, tglx@linutronix.de,
 mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
 hpa@zytor.com, paulmck@kernel.org, rdunlap@infradead.org, tj@kernel.org,
 peterz@infradead.org, yanjiewtw@gmail.com, kim.phillips@amd.com,
 lukas.bulwahn@gmail.com, seanjc@google.com, jmattson@google.com,
 leitao@debian.org, jpoimboe@kernel.org, rick.p.edgecombe@intel.com,
 kirill.shutemov@linux.intel.com, jithu.joseph@intel.com,
 kai.huang@intel.com, kan.liang@linux.intel.com,
 daniel.sneddon@linux.intel.com, pbonzini@redhat.com, sandipan.das@amd.com,
 ilpo.jarvinen@linux.intel.com, maciej.wieczor-retman@intel.com,
 linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, eranian@google.com,
 james.morse@arm.com
References: <cover.1711674410.git.babu.moger@amd.com>
 <CALPaoCheW=Jz2R3gMKcgwQe6ONDrRqu3tUxeg=A3USg6BC8buA@mail.gmail.com>
 <7ccd59b8-9fe3-4d1f-82f5-f33d96dbf5ac@amd.com>
 <ZiaRewZJnLaDSx3m@e133380.arm.com>
Content-Language: en-US
From: "Moger, Babu" <babu.moger@amd.com>
In-Reply-To: <ZiaRewZJnLaDSx3m@e133380.arm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?MzFzWjFkc2Zqc25Gekp6eU1USktrMnBEZjJyZWFBR0JLZzlhRUZDN0tybFF0?=
 =?utf-8?B?aXpXdmxmZWFWc2t1a01TL0FzVTczYUpzc1J0MDBiQzg2MHFXQnhuamlvMklm?=
 =?utf-8?B?cTJ1R3ZldUt4ekZxSUcxMzlJZjhXNmcwaUN5di9oa0E2c0RFZGlLa3BFUWNS?=
 =?utf-8?B?M2Y5bDk2UjhNOHNnVkRLVk56cEpQb2gyc3BVaStGWmpYZW5xZUlKeDRRVDBM?=
 =?utf-8?B?NVd1VUYrd1Fnb0NFYWRKbUlPUkxOSFB2cTFMalQxNW03SlpubktpSmcyMHF6?=
 =?utf-8?B?UlgzWExWbDl4dW9jTzhyQ1Fza1p5MlNaWDUvZllERENSQUZJMW5UYU5KQzZQ?=
 =?utf-8?B?QW5BVmFoWWhucWpSdUtqcjl4b1VLSmNyOXAveHpuY214ckgzVDFVbGgzWkxm?=
 =?utf-8?B?VEp6c3lCSG53dHlnK09Ja2pvSWg3RFo5ZzVrTEFZYTFKVkZzNEhTWStuV0x0?=
 =?utf-8?B?RE8rMzBxczdFUzBNelNxSFN2d1l3TEFILzgzUHY2dVRSMXVlb0NMZHpIZzQy?=
 =?utf-8?B?b0s4ZzVVM3lQY3R5M0Z3ZU90QVI5a3I2ckxkTExDTFBYSlhSa1BQdDZVaWVK?=
 =?utf-8?B?TUFZbVdXUlMyN01HYXJobk0vbVFqLzlhaS91N1pveGpQSnY3bkVQZnVQUE5K?=
 =?utf-8?B?SkpIeExtV0lIZDZXSWJvN0haZzhoMXVVU0VWcXpEWitldE1Fd011OVJsOHBu?=
 =?utf-8?B?YlVJMUJWa1F1RTk3anR3RmJXeDZqNy9UdFdvcU00bExQSFlaQW9yVnZGRHZY?=
 =?utf-8?B?aHJFenloWXZscTFTZzUyM0VCVVlYQ21FckUrUFRsaGlJUXVLdURxSDRqZ1F5?=
 =?utf-8?B?MzhvSGdpeE10R1JLUE9BR2V2c0Fsa21LaDFwYm03d0gvcjhSM0JXTFphTmJu?=
 =?utf-8?B?b1VkZDI2SmN5bjZEa1VZMEVXcnZUdFY1a0RSalpoSHUwVFdjS21RVzZIaVEw?=
 =?utf-8?B?S3Y4M3BDOGdER2tXNFdIOEIzbXBodXRpZXcxdDBSMVloT0pXeHRtSGVqTnA5?=
 =?utf-8?B?RFRnN2NsVGRsTGtwUTI3VmcxTVpFbXJGMGlxblNoRXo0VkhieFBDbEhjYk93?=
 =?utf-8?B?ZFNmbDFWcU5FOElyWmpCWXhxMWZYcDB2dUxKSFpmT0NOaC9jUHRSWEUwdm1w?=
 =?utf-8?B?anFaRWtCL3B0MHQ2cUZhOHlyY1NvSFFmbml5M3JpU2VlcHowNVBkMm9RZDhM?=
 =?utf-8?B?MmVuMlROUEkvdC85cnVvTFJTcHY5dklzN3Y3UFBFbGk1ZktGaFBSME1SaG9M?=
 =?utf-8?B?QmFld0ZlQVM2bEU3bUZubzRKSCs1WGVHeFQ4c1ZGZFU3Sk5KQ0xhckllNlJE?=
 =?utf-8?B?MDJCRkVRcGQ1MTFUYnhOM2tjaURRbDUrbUJTTm1lNjlKQ2tIT293ejI5cUlH?=
 =?utf-8?B?cnVSdTM0RUVuUk9mL1A3UldXc2dlWlQyWCtNdE9HUXBDaWszZm5FQ2FRMjZr?=
 =?utf-8?B?YjNTWFJZN2FuTDZwSDYzdkpBcW9OWGhnc04vV2pZMnBKNUxRVkF1VHM5Y3dT?=
 =?utf-8?B?TmFXdHpXNW1LWlZCY3lCTWlnZmtuQmNHdmVYQXRicG8vVlYwdVhpalNtRG5Z?=
 =?utf-8?B?b2VFM1g0aUxWSnVHb0JpQWRSbndVdzZRWkRpNlZWdGhHUU5vYUI3V000UFhO?=
 =?utf-8?B?NVBoT1J0dFI0YVM1K29GcEdBaTBtU2J3NWNTTlozL1VBTDY1ZEdtdEVMYXcx?=
 =?utf-8?B?Z0JVVm1xekhUNmlyYmdTRnh3MU5Ub2JuT0pEaldhMnZsaUw4dVU4aExIUUg5?=
 =?utf-8?B?aWJVTDdGalk3VnphdWQ2WDkrR2hmUk5oWWVWNUJ0R0NXM3BpV1N0U0dJV3FU?=
 =?utf-8?B?WmJlWGJUenQ2Q1VtTzJSOGJjU1dVdWFvb2tmQTh2cmEycERYUDkrZXBGaXh5?=
 =?utf-8?B?N21SZ2pDa3RaeEI1aFZNSmd2TWN2Tms4bmdreGZzUnk0S1lHNVBTTlF0SlFn?=
 =?utf-8?B?QUE5ZmIyQTFaenRNeTVtUVRKb2Q5U1lOUmFIZUNBc3BIQVhtdVpoY0ZXY0Na?=
 =?utf-8?B?WGQ2UDZYR0xvSDk2Rm5HaTB1TlhRdkowTGppM0FIak5jM2ZFL3IrazRMM1Bt?=
 =?utf-8?B?UU9MS05FSHVzaUowQmM0QjZlTUZGTVFoWGxvR00xWmlRdi9GZWUyeWxURHVL?=
 =?utf-8?Q?DoJA=3D?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6923ab73-85ca-45ad-1d7c-08dc630d0239
X-MS-Exchange-CrossTenant-AuthSource: MW3PR12MB4553.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2024 20:44:30.4530
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ny9Dsan/HU9fbgN5xQAJQuA+MJSLWDlwvqa3/25EkoVV6YOjSFOKGyJWN8c8vEOq
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR12MB8490

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