From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 125A13659F1 for ; Wed, 4 Mar 2026 22:50:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.17 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772664649; cv=fail; b=uOrWW3hf+J7tzA+XfFbPk8HuilVMvATB6JSySiXM9JoVoW2O1FvHur4pDA6ClRsTI9WShe+HvDnJP2AVHHF9P8vbShEzslpxQUXfQe15+pnYMIu89zXgJUEPef0Pq7lT+mSIKdZFoq9zWXd4D4Vm7EZ1B+ltL6DHvBMCkPU2TyY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772664649; c=relaxed/simple; bh=TJsMsz+qy2wDxtBEpbOpzzApCjugDGBK6uPAfwIih10=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=VAusIDtzmMDEUxh+7gZVmyy/RCXKx9ODda7HM9ZS08UQ5HuPAC692hsS6aR6rPYQtPX2JgHk6Lcz2KFP7xZTJPBQs+36pB3vFtJVOtyDOwbvymQOpP1LOyE7dok5vh2RL+/a7bRzPagTgeEyzBA+MyAyota7l9v/PRmraMwddbI= 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=gejmwT6S; arc=fail smtp.client-ip=198.175.65.17 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="gejmwT6S" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772664647; x=1804200647; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=TJsMsz+qy2wDxtBEpbOpzzApCjugDGBK6uPAfwIih10=; b=gejmwT6SB2B+EP8cGiqrzRv5bWRzzxvCzwxucJCGTZMfXKkap8+WubO4 rAvA7u73IEm+v+fv0/CTG95dNohB57vvHWTPDTGzx5s35UAJ0Y/IyFF/m xK6U5en28VzvrlJ7lvVIPJA0x5YC/dTvGE5H/OLjazQEhI4ScIvFd3Hv/ FbD3Ot73gvYwtm5e5GdjlMbmXl+E18Scvfxv8GteGuNPh29bULdz6kjrV Q+ljQ9I7gUZjieqSOxZvRz702NNxqoguulWdN3nY7Pwi+7XUz6eLZxuai RqcCBqAK6+sFr6apwr4MVL2hlYESMCJXGjI7JSGl/aA8PFyc9gaE7XBYS g==; X-CSE-ConnectionGUID: isB0L5QbTvGU9XktLkXxwA== X-CSE-MsgGUID: 8J8/VpzGQbKL8yIoTBE0wg== X-IronPort-AV: E=McAfee;i="6800,10657,11719"; a="73710726" X-IronPort-AV: E=Sophos;i="6.21,324,1763452800"; d="scan'208";a="73710726" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 14:50:47 -0800 X-CSE-ConnectionGUID: +HQgiIx1Qk+VIk/T9HSSdQ== X-CSE-MsgGUID: RLUrDCrOQGStB5RYsCreLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,324,1763452800"; d="scan'208";a="216786253" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by fmviesa008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 14:50:46 -0800 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Wed, 4 Mar 2026 14:50:45 -0800 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) by FMSMSX903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Wed, 4 Mar 2026 14:50:45 -0800 Received: from MW6PR02CU001.outbound.protection.outlook.com (52.101.48.66) by edgegateway.intel.com (192.55.55.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Wed, 4 Mar 2026 14:50:45 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Oh6zu6XPiu/ZhU435Fc7SwgjlPJafznZEAte4wCbYc1fw8gfjrlQmaWYPVqy0JTMeRCdfy4Cp87D5HwHIWte5/VlloNGvVLI0xbyIEfW8820eylq7i1U1pH/2RnhIkCehsjqlP+4Fg2Mo/JTtjTVvneOUd0E/BGZfkJqL53LEVPiG+D4A7cKAgxaw1G9zgtQfTuHkM/e/yaqbsEn49NYTf93PtihkGC4v/RPxDDtnGwamYOp7AkVgQqi4T/IAWW2joaxmb/3d/4DcARc3Xp5Le0ET3AgtJai57BqJuKYTPKgCHIhjxQoIMF7ksV2GXLHF5tGlYtqY6kreCIGpVcUhg== 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=zfN5HtuMIX2O5fAxLLxqaD/yAYeuzYEr5zklvXmq5Bc=; b=qOMqDOi4sCBm5LBLQioXyVU9FeTImK0G+EmnAwYPslPw02SXTiSsoru3w0ipqkIWSLIvkHuIe8dDx2mp3RjZ+mceJ7YstHaeZsWEP2jX8QDmyXaUMeJpKr0wXHF3APxnL3a/iv/yKTIF2LFsli1GbGcnRJhhJ6mryZUY6tX0qHHRimH52WS+N7SqatKs3dTarc9s7Play6p5L5ppvsvIg1AOnJuK+JyF4Y6g7MybklTWiJvx5n1WUUlaeLQ1xprDXSYbHb30dr5bAvtDnOi7suJMWGRh3u1QMN4YCwX53/H8ZO+NMco57Z9cFERZ+ddWAROJXx90vYFKXzgFERrAlA== 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 PH0PR11MB5952.namprd11.prod.outlook.com (2603:10b6:510:147::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Wed, 4 Mar 2026 22:50: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.9678.016; Wed, 4 Mar 2026 22:50:38 +0000 Message-ID: <39b9c59f-e001-4733-9afb-c9a0c7f279a4@intel.com> Date: Wed, 4 Mar 2026 14:50:34 -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> <5645ee7f-a5d6-4b5e-ad54-d24a11268e35@arm.com> <94fca0a8-9b60-4e00-ac69-a4e43c5fcbc9@intel.com> <7c6a1986-b23e-48b7-acad-af67bbece2c4@arm.com> <9d980366-95b1-4c9c-b2d5-76314c72bbe7@intel.com> <7e5aede6-a1a5-483d-93e2-0c8b910bc3f6@arm.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <7e5aede6-a1a5-483d-93e2-0c8b910bc3f6@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0259.namprd03.prod.outlook.com (2603:10b6:303:b4::24) 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_|PH0PR11MB5952:EE_ X-MS-Office365-Filtering-Correlation-Id: c8650e1e-7ba2-4830-b22b-08de7a407420 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016; X-Microsoft-Antispam-Message-Info: GgjXFvQpFHaAnhThd1UBIq8YVi6QjU3Op33jNNdomp8HKI9LvreZuMb5Zx4NjHZ7TQhkgSwvf2AYVfziuz+M+BWJJhnr4IDIbtHpP70zn9Fi9TfJwPzPfLlvnZUzkNPYCj9DGh/gatK1E1u8d+8krljERZhkYx8Ho1s/mu30I8TSoY62TciFH9g/LtFba/2LSYLly+zpDakTt8p9tM2LWnj6vquf5/MqxQvvvfujx8Jbxz/+XHBi7hjLHg8HMXwPx79eE4n3eBfzBMZkHyjCgWxeHxA5WMWBp0Z1vCd0eyd+LmOb7Q5dtjw5nyGyd+YxAsvU/9Di/jWleIFliegI548s4hrFWSbSklsSp4/GgiwFLHm4xlaY3WaUjOwt73oaTEPgswSmibEfaq2hsPcd/1eqzMzZw+mRTSSm8G/EYi9SLvxNvLn7Pijw3vBgECtkDF+S8rAimvTtEixOXeGu/VxWHEpRCL5XDDh5WTieH9hhUCO4V5C1V7ONGtYL21m6sSS/ePz1QZtmt0lUwdmPP7iXHucCT4N2IvQCv++XUVM+U3vB0prC6fBXICJLlEe7I/p70J4mzhDflMyYQv0cUCT4/dNhyhGf1tFFXUrjcA0h1XY87XGNXOLFtCN1nz80qRdvuUvfYssx96RgfD7Ebcs9kqJni9pZtXlH31JrMqY9EJUUt9QYO6sCrQ+klpmHGFsAZEuCop7sKCk8I1dW8gdrTHISwSmtClXAF0A2vA8= 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)(7416014)(376014)(1800799024)(366016);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N1YxWlRSOWozTWYrcUdFclF3QmJXeW9kb25pcCtCYSs4Ky9HcXNoYTVOS0ZC?= =?utf-8?B?bGU1TkswaDdiNTFicHF6V3ZKdTduQnUyV2FmTXdvRXBrdlZqUTBoT0dONzBo?= =?utf-8?B?ZncwZVdjUHhpQmJTcC9QRWtZTXQrdXdKU01naXJTUHgwM2xRb090bEVJaGRu?= =?utf-8?B?ck50VkhQTEgxSVQzRWYyRzFwMXhKaXVGZFk1Y25keUkrSWhtcU1mRzUzclRv?= =?utf-8?B?SkNiVXJ1WEl4cjVlUFlwbk03Sjd4bHRJNUJ1bkxYZXdnTDJOMkdpZldTRURD?= =?utf-8?B?RlN6VDBiS1ZydVhlWFpkeWNockZVL2tlU2dmcllaMDB4cVlIcmlTa1ZLRDdk?= =?utf-8?B?bVZCd2FuSFRnTzJCelI3K05BMk56d1VhR1dha3BsYmVjUVNOZDY2dUJsT2hE?= =?utf-8?B?dk5DMWh5MzBJL0tUUldDL0w2MEFWdkprcWZTb1p2MFBHUGx0K2ZwZjVWclE5?= =?utf-8?B?Q2hqMEE2K2JHQ3pZclh1MVVaV0xrdzllSFp0TUhDcXVkbGdrRUlZbTQvaWNa?= =?utf-8?B?eEpQWUd5VDdTQ1B4VERiZXAvYW5iV3dDSVpkZHdxNzQ1U21vT25rMnNTbHF3?= =?utf-8?B?bjdiYm1rOEJudUlWeGs1OFo5QmhjcTlWaEdXRS9hdXFBM2lMNENjcXUzVGFJ?= =?utf-8?B?K29BVmd3SkRES2luQ1F1V2pPeGN5ZmVSTHF3T2RuSjlHdFNSbDRYSzFmWFo4?= =?utf-8?B?QjZkNHhmeGNrbmppZlZ5ZlFqVElBK1lZNUZjQmlranRKTkdMOUcrRG9HREhy?= =?utf-8?B?QzJGc3prOXF6OWRpeVlOUmhabmxLVm9GRGpIZDkzZVV6eGwxNDc0L29Lekxy?= =?utf-8?B?dkk3ajFMbzdndFlzQ0h4d01DeDErd3BhNUpZaFFVNENadjVjQmF1bWNJMzkw?= =?utf-8?B?L1h0NTFVc0JRVkRraEMvL3JvMCt2MXlMTlZVeHhYQ3U3cDQyRHJCeS9LOVJm?= =?utf-8?B?TzExeklIUHpuTzM0eUVBS01HY0M0TDdXTXhicXlLcEUzRVNnZE1ocjYxaGtS?= =?utf-8?B?OExDRFRUZHZHaUhXby9UYVRIdTl1L3ZjSlljREdCNGxEQitzNHhoT3laSWlh?= =?utf-8?B?VjNKTUF2RENiQS9zYU5RRWM1TXo4ZUlHMTBQeTVDT0dUdkxoSjlCSTFGQjhN?= =?utf-8?B?RzEvSXBXVmR0QTc4TXVqK2tqRktoeVBQN21TaElHUko4c281L1V6UWpMWVJD?= =?utf-8?B?dzNQQkpjaHdtNW1XS2UxckRsUDVldDAvZnArbjBzbDhCZ3JkbUxmU0pubXF2?= =?utf-8?B?TkRndVR6VlR6cDhRNWZDbVdWSlhLUWxhOHpJdmMycEJxOVExeEtMSndtUHpw?= =?utf-8?B?Yk43Tmlub3NnelNYSlpOSm9SdUR4L05IMGlCSjB5a0FvODJHaHowcWJRUUQw?= =?utf-8?B?SzJDeHA2M0lhMktSdDUyNy9WQ0FJRFRzTDcwSDB2ZzZSRFF0RldZM2x0Z3dE?= =?utf-8?B?eDhTK2EwYlEzWVBYUVN1U1A2Zy81LzZLQ2h6YTB6R0J1SUp2ZVJST01VeUdK?= =?utf-8?B?WThZSHJOMGdWd0lFYVEzcmk2aGVjZWVNUmRROTJ6ZXgrNFZNZjRCSkVYd1dW?= =?utf-8?B?R3dYYnFkS3FpOVd1NnpXaEhPWnJzaVEzWXFhZ2tYUm1zcGdTQm9IeFVmRlYw?= =?utf-8?B?dU1ucXl3QmdwMWdmQk1JZTdPcHlYd2dOYzFUZVl1WjN4UTZXM2k5RzBkcWJN?= =?utf-8?B?WWl5OFBMRDRtTUxxQ2F0R2tldGxJQVRURTFPV2xkSjhjazZRRUZpZ2VoWGNK?= =?utf-8?B?MFI4ZXNrai90ZGV3N3RDbzBKeEJWRWFwYWE4L0tLMUZldXRTOThVUUpDYlFv?= =?utf-8?B?dEtRbW0vYVhiM2dlZzJYSGJza0drYzR4QXFUdVE3ZEIyMlNtSTFWTGV3ZDRV?= =?utf-8?B?NWNEdEdXZnFLT2VwSFlxUDNyK2t6VWpOL1pLTlRSSTdhc0JXN3A4SzBIOEtS?= =?utf-8?B?RGZSWjJCbUFaVlJsek9WVDVubUxpc1RVVEswSEs4VS9JYWZyRFNuWENaUGc4?= =?utf-8?B?bTdHcUlHTE43S3d6RVhGZHBEazlhSEYxZGlwYkR2RUJxU1p4TnYySGI1Qnl4?= =?utf-8?B?enJVaGtSTS91a2RETXQxR0tkTkgzTXR0MFFpektWSzNsS2R2VU9YdFVMWUFL?= =?utf-8?B?cGNEZTU1cUxibkE2andsaHRjeE5UVGdUU2poalJETERZekx4eEczcFR5RGJp?= =?utf-8?B?emRjcmZJS0ZMdHhPSldITU1vQ1Foamc4YUVvVE5DeFBjdmdpTkpIS3dUNnND?= =?utf-8?B?SDJrSDZjZUdobk5sbFNEcjJOQ3pYNFNGa2EzZDJVV2FWT2JrS0xsM0NWclhN?= =?utf-8?B?VmM1VGRSSHlOMXNnWDVWdUJiNk0wNnJEcGp1RXZWeU5Hc0FPeklua2RRNGZR?= =?utf-8?Q?H7G+FWg1GDROetO8=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: c8650e1e-7ba2-4830-b22b-08de7a407420 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2026 22:50:37.9196 (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: HhDQDg9og/i2fe7F/qjO1Mrj6D1DlvFiKI26VEuVavzdIyiY2delDQvYWleNnHeo1Um5uVqVPoz/17iYeeqVZFfuPLy9oz8jPEMR1xXPkBw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5952 X-OriginatorOrg: intel.com Hi Ben, On 3/4/26 1:01 PM, Ben Horgan wrote: > Hi Reinette, > > On 3/4/26 19:23, Reinette Chatre wrote: >> Hi Ben, >> >> On 3/4/26 9:37 AM, Ben Horgan wrote: >>> On 3/4/26 17:02, Reinette Chatre wrote: >>>> On 3/4/26 3:07 AM, Ben Horgan wrote: >>>>> On 3/3/26 18:09, Reinette Chatre wrote: >>>>>> On 3/3/26 4:29 AM, Ben Horgan wrote: >>>>>>> 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). >>>>> >>>>> Yes but these counters aren't necessarily fungible. For MPAM the >>>>> mbm_local_bytes and mbm_total_bytes are necessarily backed by different >>>>> hardware counters. A MPAM bandwidth counters just counts all traffic on >>>>> a link with the only configurability being for read/write. The counters >>>>> are just placed at different point in the topology to get the different >>>>> events. >>>> >>>> The distinction between "different hardware counters for mbm_local_bytes and >>>> mbm_total_bytes" and "The counters are just placed at different point in the >>>> topology" is not clear to me". The former implies different counters for the >>>> two events while the latter implies the same counters are used for both events >>>> but perhaps accumulated/displayed differently? >>> >>> For a given RIS, mpam device hardware unit of which an MSC may consist >>> of 1 or more, there are MPAMF_MBWUMON_IDR.NUM_MON hardware bandwidth >>> counters which measure traffic passing a specific point with no >>> filtering for where it's going. The filtering of this counter is >>> set up in MSMON_CFG_MBWU_FLT which only allows pmg/partid/(read/write). >> >> Thank you for the details. Is the expectation that user should be able to >> program all these counters via resctrl? If an MSC consists of multiple RIS >> with different counters then things get complicated very fast. Could it be >> constrained to only expose the maximum number of counters supported by >> all RIS at a particular scope? This would match what the existing >> num_mbm_cntrs file supports. > > Not individually, no, they will generally just be one per cache slice or > memory controller and all be programmed together as a component. Is this where the risk of double counting comes in? That is, adding up the memory bandwidth at the cache to the memory bandwidth at memory controller for a total memory bandwidth count? ... > So, to try and bring this back to what we can be done now for MPAM to > fit into the counter mode assignment interface. Just support > mbm_total_bytes and then num_mbm_cntrs is correct (nothing to do). Make > the event_filter file always display all the bandwidth types and make > that the only value that be the only value it accepts (instead of hiding > the event_filter file). If you agree I'll respin with that. >From resctrl side this sounds fine. I don't have any insight into what, if any, kind of gymnastics the MPAM driver needs to do to make the discovered MSCs with their varying scope and internal vs external counts fit into this. If initial implementation indeed forces some components into categories that are not a good match then when resctrl later does get support for diverse components there may be surprises to user space along the way. For example, user space may not see the same memory bandwidth numbers reported by the same events on the same system as the interface evolves. "make that the only value that be the only value it accepts" - are you saying that whatever is displayed when user views the "event_filter" file is what the user can write to the "event_filter" file? I find this a challenging interface for user space to use. The expectation is that the user can write any supported memory transaction to that file and when writing fails it can only be because of an invalid memory transaction. How can user space know that events are not configurable at all? It sounds as though user space is expected to try configuring the event with a memory transaction and then, presumably, check last_cmd_status? Could this not be simplified by making the "event_filter" file read-only on MPAM systems? Reinette