From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A771B381AFE for ; Tue, 3 Mar 2026 18:10:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.16 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772561449; cv=fail; b=MDsWheN8UBnqV9c6m/wJn11J+ECk6v8SI5VZgAznPZI4B8h3stE6K/G1Tn/VEerdReUlMiIKJVTpzBf38TH+bHDvFzy78QP+Me/q+rOrIU1nSQWtlC2VR7w+8q0kadG3kQt5dFurMvqgxHWrCqybLzW3CJHalw1B8qTs2q4R+7U= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772561449; c=relaxed/simple; bh=G7Afo+0znPCrWNruU7z/Vkxbh+O4mbPwTtLCbV4QnOM=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=R7LMqjYYQPBSyOhX8V9jKASxdPCJlPYgPUETZRQOPLCwvY3CBbOLNnC7YQStlzJZegwH6XfZf/671a/q5wbCNFN/6c0NDwBerrEYIFWl1niK2mal/Ha6026PG2Vv7c/rztEKVqhrX0MYfjmEMe7gFsuCGeyYGySuxSzm3nigKe0= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=SE2DCKfn; arc=fail smtp.client-ip=192.198.163.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="SE2DCKfn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772561447; x=1804097447; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=G7Afo+0znPCrWNruU7z/Vkxbh+O4mbPwTtLCbV4QnOM=; b=SE2DCKfnXOuWgV5Pv3G1ya3Yx6xGfN1ccfD/OgZz+iGnLCvmAZ56e+f/ x0Gyn7VZhCKtL+Wp4cX/mqPBYUZ3D2JFnYe6PE/leXBrmJ5k4hw1tS6g9 99yFrH90Fl+vhffVnfYcHcb5gTaJRrhOWrMsg8QkIePYtbivvORmUv0Yp uNlZSUPZx4Yf90hiw2ni1i3hEjShTJbYymaBsFHaky/m9/GZVL0BOwUrR R2KeUPoIT+rxYsTaG6retUtxLoM5c+/3GNeDKz4UxVnzOwQohgvEcPGLQ 9H+fuuWtSvZJRn+Vikd62ADQm2eYinX4sjYmG0UyWM+Vvk+mZ6qchSpN7 Q==; X-CSE-ConnectionGUID: gVGyLKMYTQiszeZx4LyGhw== X-CSE-MsgGUID: fx0a4CX9Qq22u0CJZpO0AA== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="61187977" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="61187977" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 10:10:46 -0800 X-CSE-ConnectionGUID: j7PW3o5HQaqRVbb521df9g== X-CSE-MsgGUID: fF1kM2cwT9aUDm5+kJzOCg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="218203660" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by orviesa007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 10:10:46 -0800 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Tue, 3 Mar 2026 10:10:45 -0800 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Tue, 3 Mar 2026 10:10:45 -0800 Received: from BL0PR03CU003.outbound.protection.outlook.com (52.101.53.0) by edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Tue, 3 Mar 2026 10:10:45 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ghMFlvKkNzVE6Djaql3QpcK/Y5+Mufet6fiHgn1rxyO29HHJHvOlSUt2bRwCqvquA855Oli5sFeJBH/0xOQ7w13bEnAPiqrHD/SBWUxIOdzm/jPeBRXAPLiOw/JR9D7LIkgF9T90Pf0mtMquKoIQBorE83N/anr9X4T4pu+y/L0y9/rjI8H0MbCKCFKKcQBv0cjWYEnboQ3Fhm8Wek2wlkBPbgpt74ZOkqZL++B7FdA5qvAt7o+D548qUBF82jZGU96J90xvTsarqXd/zp6vZkXNT4/A8K1zkzT+5zhKalI0UDUXT5eGTSWI+wq8qRXtg9wMd8AiSNF9c/ObZcKrvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Uske79F60rlAwO9GSDDDHcBuxU9nmHiLVQ1YzzyP9D0=; b=qlEPGVH7CvrAkvcQwmH9+EgSLg7CHsddzzZAUju/g9KQVoVQuiYFFdmOvRwVpSMEmUXNAThztk7RSOegU/gOdPAGjmc8U4Jn4ib0E1MSgETuUuEi+kOTWLcGaZhYi9rUJDV+66S37++5a3jx/rKeRS+FQUbkSQtPfVY2ScnQVTeHR0fJeActPPVQFdUSJ4b/Wd+Q+F+HttLyJAOXTtxkDbMssMRdOPNLY7z6CH2w2Wm0SBYQJW43XUvGNPigKRoxkON2S0M0NZrtZGKUzlVb26KQ4pqosh9PSdUKLXdH3uIqLOMW5s9cPBGYb+xUvMzfxhWmO2PMN5ZTxFvEK57o+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from SJ2PR11MB7573.namprd11.prod.outlook.com (2603:10b6:a03:4d2::10) by SJ2PR11MB7576.namprd11.prod.outlook.com (2603:10b6:a03:4c9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Tue, 3 Mar 2026 18:10:38 +0000 Received: from SJ2PR11MB7573.namprd11.prod.outlook.com ([fe80::bfe:4ce1:556:4a9d]) by SJ2PR11MB7573.namprd11.prod.outlook.com ([fe80::bfe:4ce1:556:4a9d%5]) with mapi id 15.20.9654.022; Tue, 3 Mar 2026 18:10:38 +0000 Message-ID: Date: Tue, 3 Mar 2026 10:09:04 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/4] x86,fs/resctrl: Make resctrl_arch_is_evt_configurable() aware of mbm_assign_mode To: Ben Horgan CC: , , , , , , , , , , , , References: <20260225201905.3568624-1-ben.horgan@arm.com> <20260225201905.3568624-2-ben.horgan@arm.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR04CA0101.namprd04.prod.outlook.com (2603:10b6:303:83::16) To SJ2PR11MB7573.namprd11.prod.outlook.com (2603:10b6:a03:4d2::10) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ2PR11MB7573:EE_|SJ2PR11MB7576:EE_ X-MS-Office365-Filtering-Correlation-Id: 5cc04833-ea42-4fa8-a1a2-08de79502bf2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014; X-Microsoft-Antispam-Message-Info: ts77XpzXA7TzxqoZu273xxvWpQIAUlXJIcaT5anGgduehlAHgA7vo11/zGDNHjc7nfYw3Jym+N/2yrVOR8JeWIGFTJNuCyGXaF1bx3VIPWGFt3P1wj1Q+UriZk84qBrLpjFTN6qG/CxXLwYRosdY01AtdU/Z9Fw0RogSg2PBXGQuxK0mEmCvzLLyqRqhoGPwDxMCiJ+S198aikMY9eTI7C70nL8ZeiP8F43WzlC7aXcQknUFFkLXGDcl6uXpfO6LdLugowFU9pCrwqCJ0PCy2pEfbL1B17M/Jk2QlaAQLBcufOyQyRG/u49waKs89SIAdDBRIaB1YS0uNaWqeaInU9wDxkz3YzP7pl55acdzPayIM/JsJaLYRHfmZaS6pgIWvnK9mvJKI7tq5EI7eGVo+e91hPICdjZo09CyRThsNOgU3CguHbJl6/51weVauBukMEEtr8fSL236Zatbij29pgP9YVtmgdpGf5wLaJLY1G1jNiCBOzLnbb3D9x2ccyJCbTSwYPplHHQb8jrEEz+SLyfWRBIjKZ2xvubKkoSro+9RRjExi/m9u+cfqfgHIZ2NHBJxYnNIccLPUVheSJPksujXPB/RM0+CmP5uYrdrBE4zBdCsoCBc7rKP8tlzeHEzEvK8M2PnkeeqCq9SmY9RslHwGsp6Nam2ElTZmcSQvZIuvd6TSOXKRG6dDgsqutcfT6IcFbJ4MGf0+wWHCD+bKv31uckN4DUn/d/u+ExPq9s= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB7573.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cGtOT3NRTm9WSnBUdlJ2ek95M2ZoVy9xVzluUlRpb0poaTBoWnpyRDBCbUpV?= =?utf-8?B?REtYcFM2YUxPek91Q3gwc0ZPeXhLeVpzZTg1alRUSWo4T1hpYm1FS1dyZmJM?= =?utf-8?B?RlU2aStQQVFUUzlaMW9yaU8zdC91VnNZc21icWtIRFZKODE2eVZVRFJ2OEhD?= =?utf-8?B?SjV1cUVYRkxaY2lLNlZmdTRDOWNuQXdzS1JxMjZZMXFxdEpGZDBoSUF5TzdS?= =?utf-8?B?a0J2bERFajliM0dKUjN5R1czL2hmUWdLM0s2VWNRQXNRcTZQTDJFOGJsNnpa?= =?utf-8?B?V0h6NUV0OGNMKzJ3Yi8zbmdvd2s0RjVYWW00QzhkQU9jQndKcGZldm5sTVov?= =?utf-8?B?RW9kVHNqUzlYYnUrZzNzdXZEMEE3bUw2T3dOU1NOUmxTRkorNitaTURXaFQz?= =?utf-8?B?QUxlVlF3dElQalJTbkhvVGR2dXFBNWlSS2JKbitab21qOFlYeU53cnFMSnFk?= =?utf-8?B?YjdWNjUwNGlHc3NoOHI0OXJsckU1MnNkd2liY2NOREdRQTBicWNRdWhKbGhS?= =?utf-8?B?SW02YXlaSDJOd1l4R3l0Rm8zdWRzdlkvVzMyU0ltMTlrelFSKzgrZWdTLzA0?= =?utf-8?B?ckIyWWtyQ2Z4NG1xeE9JcXkzOXBaRWRXR284R2lnV2E1MFV5TG8yeXF0algw?= =?utf-8?B?RmlOQXNyT1pDMFk5R2lUWkMwZkJWbmRTUUsxRC9rT1hmWmYxT1g4SmN2ZTJP?= =?utf-8?B?UkZMei9qVHlhSjhsTEFPZTFlRVpzb0IyQjJCdkEzdzFaMVdxTm1Kd2hYQWdt?= =?utf-8?B?MVBGRnJYajBMQ05DZW5UQUFWcVVtV2E2SlFYaUJ0MFBrdzF2Z3pBYzJuOXEy?= =?utf-8?B?ZzNRalVTWWdja0xQMmREZDBZN3pvemE0Y1BSOFVMWHQwZ1NtYitIZ0pRdzUy?= =?utf-8?B?RXFubWNkZ3o5RnBhVFgwL2lPMndTcWxWV2FHQVIyOERwd1k1VnhQVTA1aG1v?= =?utf-8?B?RytJVStqeWNITjFyMUJuYlpTMXA3c3lXT3dSdFBjQW5mUXozemZhaEV3QllP?= =?utf-8?B?cGdZejVTTTJoY3dNMU91TTdjeStSTzFRd2Znb2MyWjNzcTNPZXoxc0dHVndW?= =?utf-8?B?VURkcHNCZ2lXRlFXY2I0TXZ4UFk0VGFCaXpxU1RoeGtpUk1ISFhpOFo4UjJr?= =?utf-8?B?QTRTdjNIeHBDelNZWDQwSWxBelNDMHRCWUZGd1JITHRHTzhtS1R5bnJ6d1Qv?= =?utf-8?B?Uy9DeHJCOWhxdGJGaHlQSU1XR2lyQWNYL01LZmQyVTdkaWFXTENULzZ4M0tX?= =?utf-8?B?NFA0SjVKaWIxNUFlc3A4RlozZXpmVHAwMXhDR1d0WlhJTERIeFFwRnpnWjFh?= =?utf-8?B?QnR3aDk0WFJsRFQvZG5IdEErRDlpZk1sMVczdWo5dFc4ZGRDUk8wLzJMTy9t?= =?utf-8?B?STQ1OFdsWmRWSjJUYk5TQ1pZVml5OGovTjFtU29Xa0FkTmhibzJiV3ZUcFkw?= =?utf-8?B?YlZNOFB1RHB0ZFFaTk1jZ09zeVFYL1N6UFlNeVoxczd3b0x0OCtZblljdTFU?= =?utf-8?B?NVVVMmdJN3dPTW5UWnFzemtIelc0NUZyS1kzOWFyYUlkU1pMbE1iVndKSjJv?= =?utf-8?B?Tk1oT1RRRVRuZHVERWtleXk5RmczMnJWcTJVcjNmbGpaYXI0T3VZMGJKTitF?= =?utf-8?B?aGxGQkFDeEw0bWNrK2pvbUcvajE2K0xzUTk2VlIxTnkwR0RoajRmUVV4NkFX?= =?utf-8?B?eUhURUl0enNPY3dlM2RrMlRNK3FlVExLUWlYU01kSXVlU1RtNjBOWnQrdUx6?= =?utf-8?B?Nk5jQkJwa2E4TmhOSVdKN1FIRlJrUS9JVURBYWdjNFo0bU1pZHpiaUF5QUFV?= =?utf-8?B?dzdscytNdmcvT2dxU3NoMzhtMlZCSys0dlB0WmcyUkZVVFh0RlNEeXZFeHor?= =?utf-8?B?ZEVyQWg4bHZ2VkJFMGNWNUtuaUlSTVc4YlZQTEpsRHY1Wk9UdUhXTHpMaW1y?= =?utf-8?B?SC9rbmVEZVVteTJRZnRzNWs5Q1Fnc0I2SzEzRDlSZ25ROGRBNU5rWkRpYkU3?= =?utf-8?B?Q3lhQnNlbGo0UkEvWUlhSW1lRFkxR2x3Rkhtc3lHdWpCWXJpUW1kUExUWFhq?= =?utf-8?B?Rm00VTNTNnFvRlRKck5lc0hZQ3krOFJNM01WeVFRazYycUpLVDlQbm95NlF1?= =?utf-8?B?NW5EVjNrR0w5NHZTOTljQUlZQ3Evc0NmcVNRQ1pQQVdMeFlGREtuWFMrb2NQ?= =?utf-8?B?RklMTkZ3dkg2Rkl3dDZ4VnFmcFoxbk9vSFg5LzZmWlB4UlArS0NnWEFENk9X?= =?utf-8?B?Yzl3YnZqdFRlS3lrT2dxclg0Tkw0eVZMTEV1Q3pDZFRIZThISUlUa1VZeTYx?= =?utf-8?B?ZVd5MXROMEtJczV1SEFzZDBEYzlIS3Z6bm40a2Z1emtTbjZJb1l5akFvWkZh?= =?utf-8?Q?2uLRkm8G2bCQ1n4g=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 5cc04833-ea42-4fa8-a1a2-08de79502bf2 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2026 18:10:38.5072 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4iTMfnbLP8eWdzAh8/wk1pD/+2UShowkfGnV7v+XmnV+HKpOnYKkRLk/z3iUOBi93b94chHIo2WILlPPSOfoC6p6oDWtcxPCikBkdQY6y+Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ2PR11MB7576 X-OriginatorOrg: intel.com Hi Ben, On 3/3/26 4:29 AM, Ben Horgan wrote: > Hi Reinette, > > On Mon, Mar 02, 2026 at 03:11:48PM -0800, Reinette Chatre wrote: >> Hi Ben, >> >> On 2/25/26 12:19 PM, Ben Horgan wrote: >>> The features BMEC and ABMC provide separate interfaces to configuring which >>> bandwidth types a counter tracks. Currently >>> resctrl_arch_is_evt_configurable() only ever returns true if BMEC is >>> supported. >>> >>> ABMC is useful even when BMEC is supported as it also provides counter >>> assignment which reduces the number of hardware monitors a system >>> requires. It is an architectural detail that ABMC provides counter >> >> Since the goal is to support MPAM I'd suggest that the first focus be on what >> resctrl fs supports and exposes and how it does or does not work for MPAM. >> >>> configurability without requiring the prior feature, BMEC. On MPAM systems >>> these two features are independent and the bandwidth types are limited to a >>> choice of only read or write. >> >> Does MPAM support exactly these two features? Specifically, does MPAM support >> a feature that allows user to configure events globally per domain and another >> feature that allows user to configure events per PMG? > > No, the bandwidth type configuration in MPAM is per counter and so effectively > per (PARTID, PMG) pair. In supporting hardware, the configuration is made in the > RWBW field of MSMON_CFG_MBWU_FLT and allows counting of just read, just write, > or both. Thank you for confirming. Since BMEC event configuration is per domain I do not believe BMEC is relevant to MPAM. >> These different features are how I understand assignable counters and BMEC to > > We are each approaching this from a different view point. I've just been looking at > ABMC as a way of dealing with systems where there are fewer hardware counters than > (PARTID, PMG) pairs (num_rmid) by requiring a counter to be assigned to a > CTRL_MON or MON group in order to be usable. resctrl otherwise expects a counter > per CTRL_MON/MON group. Sharing bandwidth counters doesn't work No, resctrl does not expect a counter per CTRL_MON/MON group - in assignable counter mode the counter assignment is per monitoring group AND event as a pair: (CTRL_MON/MON group, event). > as they need a fixed (PARTID, PMG) configuration to avoid missing counts. It is not clear to me how sharing counters are at play here. > The intent of this patch is to allow splitting these two features of ABMC, > bandwidth type configuration and hardware counter assignment in order to just Why keep BMEC which is by its name does event configuration? And then on top of that it is event configuration at a scope that MPAM does not support? > support the hardware counter assignment. > > I'm still not understanding the distinction you are making though. > The files are, > With ABMC: > info/L3_MON/event_configs/mbm_[local,total]_bytes/event_filter This is an event configuration that is global without any assignment. This interface communicates to user space which transactions are counted when this particular event is assigned to a CTRL_MON/MON group. This interface is intended to be extensible. The interface starts with the original mbm_local_bytes and mbm_total_bytes events in order to be backward compatible. The vision is that if the user prefers to count different transactions then they could create a new event with the transactions needing counting. For example, # mkdir /sys/fs/resctrl/info/L3_MON/event_configs/just_local_slow # echo local_reads_slow_memory > /sys/fs/resctrl/info/L3_MON/event_configs/just_local_slow/event_filter The events are just tracked and managed in software with the above interface, no hardware configuration is involved at this point in the above example*. The new "just_local_slow" can can then be assigned to a monitor group via mbm_L3_assignments that will at that time consume one hardware counter and program it with the event (which transactions to monitor) and monitor group details (PARTID, PMG). This is based on original suggestion by Peter in a way that we thus expect to work for customers. See [1]. > and with BMEC they are: > info/L3_MON/mbm_[local,total]_bytes_config This is essentially both an event configuration and assignment that is not compatible with assignable counters. With this interface the user both configures which transactions are counted by a particular event and programs all counters in a domain (across all resource groups) to use that particular configuration. Due to this incompatibility resctrl fs will not expose BMEC files when assignable counters are enabled. > In both cases they have allow configuration for two event types, > mbm_local_bytes, and mbm_total_bytes. What am I missing? The way I see it: BMEC: per domain across all resource groups event configuration and assignment that applies to all counters - intended to support the "default" mode where there is no counter assignment from user space. assignable counters: event configuration via event_filter with assignment done separately using per resource group mbm_L3_assignments file > >> be and to support both at the same time requires a user interface that is >> confusing since the user can concurrently configure events globally per-domain >> and per resource group. > > Sure. > >> >> Could you please elaborate how event configuration work on MPAM? If find this >> series quite cryptic. I think it will help if you could elaborate what MPAM >> capabilities are and how you expect resctrl fs to expose these features to >> an MPAM user and how said used is expected to interact with resctrl fs to use >> the features. > > Ok, firstly regarding hardware counter assignment, on MPAM systems with more > (PARTID, PMG) pairs than bandwidth hardware counters we'd like to expose the > mbm_L3_assignments for tracking which CTRL_MON/MON groups have bandwidth > counting events and otherwise not. ok. This sounds like assignable counters to me. I do not believe BMEC comes into play. > > I haven't put much thought into how we would support event configuration with > MPAM but we would want something that allows the configuration per hardware > counter or (PARTID, PMG) pair. I'd rather not commit to the existing interface This is what assignable counters already does, no? > as this looks to commit us to per event type configuration. Please correct me > if this isn't the case. > The existing interface was created with MPAM in mind so I do hope that it can indeed accommodate MPAM. Reinette [1] https://lore.kernel.org/lkml/CALPaoCiii0vXOF06mfV=kVLBzhfNo0SFqt4kQGwGSGVUqvr2Dg@mail.gmail.com/ * If the user changes which memory transactions are counted by an event *after* this event has been assigned to resource groups then some hardware reconfiguration is indeed required.