From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (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 0D4173168FB for ; Tue, 3 Mar 2026 18:16:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.21 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772561815; cv=fail; b=imL8w7Xo/LWxnGz6MzHK8yUIfJaNX4rEagwPTFu4Cd6ByVu/U1rKqOzywL/3gcfgWK9ShEHCjj5cMxTXmToa0zaQaLH31amAIHZYH4/H5gUj2IMxBhIszJVR5lrN/XPOmNCej8jNTDoaayVKCb7KeTrVETke+/hRU2jhWtsZHTU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772561815; c=relaxed/simple; bh=Ecb8Oj9PNy08wUgZktbGKdqjmdUmL5X9fxyhA7omQ24=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=ssP8OVqJfgzORvTJYy1LOVTZWJ5YHdlu3E2jORDquOfMTQQ8BSRnwl04nVnq6dlP+xRpCrCDckXQj7dUdK40v0BI6s3meuTSvlmzURc5H8sbC2Q0j5zq9zYa2v6XIQmUSuLKpVsaSAkgoV6A4IND6LqFBt/LyRAJgMrjgv40gT0= 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=OM/JQcor; arc=fail smtp.client-ip=198.175.65.21 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="OM/JQcor" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772561813; x=1804097813; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=Ecb8Oj9PNy08wUgZktbGKdqjmdUmL5X9fxyhA7omQ24=; b=OM/JQcor9vzvkC+t0KmygYWe4eXbFJJjYN67ypZzLGmSSJBd5YEItmqE MtYNxcpFztETv/Q9LM/iGT2fRwtwLeS4BanehXhEfyLKIWadAvut4sF6N sgtswnO0xMJrOEKpRMaqHKc1fBqdKYF4RYZIKzrcdLF2ZXUS/BW4aTpzU qL+ewiRGwpVe1y18Z8AxIRNPizZgdm2NOzi6Ron2vUC86iGnjjtjJKLHA m5+LozesitO+wH4fP26xHNCKPWCwImv/53Oq+Reyd+ildLtpHOpf7T+4J x7n4UaQiAaUk+/gfQekVwYQzxQs+dS7L9JNP5iWFmgROWB7w6u4Y78CxZ g==; X-CSE-ConnectionGUID: fIctmFLZQqKsIVePGWXpgA== X-CSE-MsgGUID: 5oglBdHHR3WWL3l9UNvR8A== X-IronPort-AV: E=McAfee;i="6800,10657,11718"; a="73484539" X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="73484539" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 10:14:55 -0800 X-CSE-ConnectionGUID: TJrB8z0GRJqsd/p7+m0fDQ== X-CSE-MsgGUID: 0dQ99sR+Qpm3lE+FJj5mAw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,322,1763452800"; d="scan'208";a="218052372" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 10:14:55 -0800 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) by ORSMSX902.amr.corp.intel.com (10.22.229.24) 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:14:54 -0800 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) 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 via Frontend Transport; Tue, 3 Mar 2026 10:14:54 -0800 Received: from BL0PR03CU003.outbound.protection.outlook.com (52.101.53.40) by edgegateway.intel.com (134.134.137.112) 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:14:54 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kI1lQZrICK07XwoMFRNb90u28T7azMRSYbHhZKQ062Bm7u/717YXK6CFS7+LutwR0lK/AxLHUToxQ9y7TSQP5ToEpF4OoNGkwTcsDIkXjrhXqxaKVU5Lw3WC0aM0/ICgasT7fWQAeQpcS1AtjJOwJsLBUFHfJvWoTu2h6RTtNqb6uw26pjqmHph/IUhfa6kApB4RUMUosaLzBmQsQFqcSUaqxr50hU830QmsIo4tyhUlAkJDG2uNqHI0exli38mfdnt4fxps4yah9nqB5233OORPAziA5hqCu2OcF/drvkNEBD4HIouV9c4zx5NevJvPvckKvpgfm7sb2aWnKmRAlA== 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=cQzI9WsZZCjp3P0wtxk8TGnaOyRuSKiQME/6he6AKlA=; b=YHTrJbHGXPUQtWJeAE0FttAkq8a9faii0ch1yunLBa4SiAllRKghVjqR87LAqHTv7gESqAAqAc6P6wWbhOXOHnr5jsPtgLlIMEGWk4hb62vDZw92Dkk6IChfao49b0PUGgUaINSJtiqa3wxrBFv14Si/IHM38IfLM4Ppfg0rat5P8th2WR4JlXFosFg41iymQLiWa/DavM9duNZCvOb373yffEsZrQTOFKkPSSKJ2LINl91XbRIDwum6CJrrJPQw+aByGd/ZboeDbux381a9NAu67OTXnExfMPokzGCRLSyeNZ2042+YMEcqEpvnnXj7qbv4+ZV23GZLaepXM4dvCA== 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 MN6PR11MB8194.namprd11.prod.outlook.com (2603:10b6:208:477::21) 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:14:48 +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:14:47 +0000 Message-ID: Date: Tue, 3 Mar 2026 10:14:45 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/4] fs/resctrl: Only show 'event_filter' files if events are configurable To: Ben Horgan CC: , , , , , , , , , , , , References: <20260225201905.3568624-1-ben.horgan@arm.com> <20260225201905.3568624-3-ben.horgan@arm.com> <7c043aae-7495-4fa9-a630-ec9e1606cee5@intel.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR03CA0088.namprd03.prod.outlook.com (2603:10b6:303:b6::33) 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_|MN6PR11MB8194:EE_ X-MS-Office365-Filtering-Correlation-Id: 61f0ad99-fbac-4a4e-6c7b-08de7950c115 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: 124cbE4jCujMTmC0Qw3sNdAf7IM5kXnGc6L5IE8uDlSqqtjsBy7h1/lh6aRV5GdAoj2FDns8kT01MSNFuc5K9TyqKg+H7tTNj0N14zHoRNGH5C5sZnA61C3HnXdfeMlSMeE/vrhvN6sccHqzxvp+b0FK77ajI1CViwxdztDnVL1ZQHUuonfDPmbyp/Qr7QGFeYM0sxBkDHRkyhqlsFgJCX295ygpATYIhZDBIz1DTEalha2QpbC6gbo/gmoGLysT7Y/aF34YxbdHT0Dl1rN8XKu+d+F6GIkNuaR2PQl7dw8OrYnvJ+03d92o0gL6EzARHH6PtS2q6o2QcbQK57z4RcmkXDQxqEDBg67whhw09GVubiZi606Qpc/T63D6oX4/4Krh9fwALU4+T/6C6C4fogXNXNvPMypAI+qERYiC4qYljuRpBHPkeyvf5NaPRQVP5z5V5pzHmfM2owL5COfZ0Uij+K3Kb53nAxoZRDdmix4sFAKNjRrw2w6wQchGQMFJ+lnLHlON94R5b5qOtiGAGdvvj5xL0k/Uxu1coAvskN6ke/j+MKfZ7sdLnIn9iz0qMa3d4aQW1GhX6N+W3xs/sO0k8YfI7P04E+iHN5uV8OV4DNXUJmdx56bWU216uheTii4ti6JkMOJfld49SL6JDv0Ethaf7qq+1tt1ew7jZnApQ+QRU3PXZUOD7JXXZ1L8EQOsNztWCMEep9+r1C9iCa9lvLGSVOXa//u4UjEk0TI= 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?Z0wycmtBeEEwWG9hK2NXUnVYaUlzd3pnQzlXWXRsblMzdE82OFp3TVpMS0hU?= =?utf-8?B?L1l3SFlZSkx3a3FrakM3ZjdHWEtIaERGSkhicnpZS0pJSk52cDJWYWZ3NDJL?= =?utf-8?B?VGhKVURDQW8wSC8yUXBKblRIbGtQZTFzekNFOE5aTU02UHFQK1dNNG56QXpD?= =?utf-8?B?aE9jWlRjYmo3azdjUWVwVS9vNUF5MkVoclJkQllLUzd0Z3Z3L0VoRUY1eUty?= =?utf-8?B?eDBZRnducDAxVFEybW9XMXNiYWFWSkhZTTN4NGVZcXhpUnJaSXNXMkY1dDVZ?= =?utf-8?B?cHBJaXlIaUpDWnJXRWs3TVlzWGQwOU5GUFRtVTI0L0h0ZnFpcVlwOU4zWm8x?= =?utf-8?B?RHhZa0ZLYlU4cHRKRE83cTk5b2x5aTVGSnY3c1JrQTJja1N2alRpZTlRWXoy?= =?utf-8?B?dXRZbHVoU3FXU2Nqd1NzSDNheDBkUnpSaEJ4VjFWN0ZHZi8ySDdReVpja3F5?= =?utf-8?B?Q2R4aHhIbEMzZFVJYThWU3BtOXBGZVl3amVKcUhXQjRIY0drbjJVU3RsZ2ZZ?= =?utf-8?B?NFAzWTVXK1ZWakdWMllKN0NxS0VMajN4a1NBVE0xVWVxbi95SFNJc3FxZXVr?= =?utf-8?B?bkdPbktuTlg0d2pYSXZ6bTBMN0pqMmNpMzNRVzF3TSt2R1hzcS9LYVlraE52?= =?utf-8?B?ZTZ6aU5XdFNEVC9lSmhLaWhoY1RlY3RGS2dCZEw3anUzYVlSYUY3SUpRVnBi?= =?utf-8?B?YTFaSHlZTDg3LzdYemFCZjhlQ2lLdWVSY2prNUpMREFsenRFS1JqMTJvd055?= =?utf-8?B?eVBJSmhBbzQrbmk5WXQzYXc0SWM4ZWV4WDN4MFQ5bjMrQ2NwU0V1NzRxNFUw?= =?utf-8?B?R1JJa2h1UEFIUzZFU1kzdFY1dnk5ZGtUL2hhVThGRERLdVJkazBQS0NwZkZN?= =?utf-8?B?TDlIRVdqUk1NZ0xCNGRONU1UZk5hUy9TbFdDcnVkTXM2bm1MZ01BVi9vSmIy?= =?utf-8?B?VTFvcm1Eb01UZko1WitiWkRXQTRQZEpVZFZuNWYwUXFGMkZveEtuMUlpNzRT?= =?utf-8?B?dUtkYnZiTmxQdjkxUFczN2FocjN1VkliMWhsOGhWL2J3RjJRN3dqVFV2dkdk?= =?utf-8?B?NXlTK1lEM1VIWElqR1Zqb3lMYkdodU1HL1JDbGE4VmRXektEUGRkdTE1ZGl4?= =?utf-8?B?cGVaMjNwaWg2T1NwYW5GSnRYbnlqNG1BcGtwT2lzczJ0OUVjdUtyQlFia0RW?= =?utf-8?B?a0YzcTE0Tld3Z3NoSDNCckVlSjYwd3U5ZTc1YnErckxhT09ZcU9TVHJFWk11?= =?utf-8?B?RkJGTmdZOXVUdDJ3QWduUzlvMlRxaTVnT3dVM1cveWpzSmtJWHM1MW84SDhn?= =?utf-8?B?WFo4Y3BZd0I2enhXWHVaRkhWZ2d1Z2JCOWV2MTE3YmQyWXVqK1hSbi91K2N2?= =?utf-8?B?b0hacDlIK2F1NG55K09jNWxGYXh2NEI5UzVUWTdwUE1qSGNWSzVkalNHQ0cx?= =?utf-8?B?MWxMWlFtWkNBR1ZlWTlnMVNGS3lycU5jWjB0QmcrQThkaEg3MXNPVWg4RmFx?= =?utf-8?B?c2tvT2ZjaVlPWGh1QzZ0ZDdsOTFEaURIUXRFNnJodUdpTW1hUm1ZYWRNWFdH?= =?utf-8?B?UytNUVRBUTVWaVhpKzBJUTVhN2IrcjRqWXJBRmFCYnZWNHZDYXRQa2tsamZr?= =?utf-8?B?YjIvV0MrTkhuR2dxOTJac3hBTGY4SVpQQ3JZUnNRNXRqaUZ5TG8zUFYxSFcr?= =?utf-8?B?eTBzMmRZZGZka0dHalAwWnlBeEtsVnFsS2tTZHdQNnRDV3F5RzFScHZqWG1P?= =?utf-8?B?QXRhQlBwbHNyUzMzT0N2ZVluanNxWDhjRHpYR25nc2lmV2pCVE0xNCsyT085?= =?utf-8?B?LzVteG1hNEROaVZFbVpSbkJDU3ZwZzJ0TzZUUHRJZHc2UkNBUDhLNW5jb0Rj?= =?utf-8?B?bVlJbkdaR1Jyak9XdGRCNTd2V3VDbTY5bjNndHd5amsxMmlTamFlRlBscDJi?= =?utf-8?B?ejF1R1MrV1NtUHJTRFk2T2FlYUIzVEs0TE5UVytmQnJEdTRYZjM1TzlUdVh3?= =?utf-8?B?Y1M4dm1tNG82djlxcm11WnJ6UHdNTit0UUpYbmVhSnVKVkJWUEFobE9QdXFH?= =?utf-8?B?bTcxQXZRUDVwelgyK1U2QVphcU1MbUhaNlRITDdWWjlvcCtpSG1Lc3UyWUJP?= =?utf-8?B?Tkw4QS9YTmVIV2hGdU95NlFaUVZselAreEVzQnkrNm1FVDVtRFVEWWpHWi9a?= =?utf-8?B?VHlnd3ZoSk43a2xSNTNsenhaeTViRXNoRjB2U01BSk56cTN6SVZEUmVwam1r?= =?utf-8?B?QTQ3VVF1cnNVaWlLV2hFbDhNUVpHaGRwS09sL25qQkpHRkRRTE1uNDdwKzhs?= =?utf-8?B?SzFaeThWWCthOGM2MitxQlJBelNqQURvN0xjUDVOM2d2cklxTGZxUllUSGE1?= =?utf-8?Q?boDEfHXEMXO4YZp8=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 61f0ad99-fbac-4a4e-6c7b-08de7950c115 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:14:47.8363 (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: aXNgmS/QIe4ztkV8syP0qrEB5L21l3IvyvYw2KCgqipat4dXlSt50ny9xkwiLmMq+FJihfX6xQEcN1S6zBEADWp/WeXlueFsee5USW2OQRg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN6PR11MB8194 X-OriginatorOrg: intel.com Hi Ben, On 3/3/26 6:00 AM, Ben Horgan wrote: > Hi Reinette, > > On Mon, Mar 02, 2026 at 03:12:52PM -0800, Reinette Chatre wrote: >> Hi Ben, >> >> On 2/25/26 12:19 PM, Ben Horgan wrote: >>> When the counter assignment mode is mbm_event resctrl assumes the mbm >>> events are configurable and exposes the 'event_filter' files. These files >>> live at info/L3_MON/event_configs//event_filter and are used to >>> display and set the event configuration. >>> >>> ABMC always supports event configuration but for MPAM they are >>> independent. Decouple event configuration from counter assignment by only >> >> Could you please elaborate what you mean with "independent" here? If event >> configuration is still supported when assignable counter mode is enabled, why >> can event configuration interface not just remain as-is? Could resctrl not > > The two features of ABMC that I'm claiming are independent are: firstly, > requiring assignment of a hardware counter to to CTRL_MON/MON group in order to > allow using bandwidth monitoring when there are fewer hardware counters than > possible CTRL_MON/MON groups (num_rmid) and secondly bandwidth type > configuration for the counters. These are implemented separately in resctrl fs. > The first is concerned with which, if any, hardware counter is used per group > and the second with what the counters are counting. To me these as appear as two > things that should be considered separatedly. Is this clearer? They can, and indeed resctrl manages these two parts of assignable counters with two separate interfaces. > > I'm first trying to address the case where event configuration isn't supported > as we haven't currently got support for that in the MPAM driver and supporting > systems with fewer hardware counters than (PARTID, PMG) without unnecessary > limiting the exposed PARTID/PMG. Some MPAM hardware systems only have a single > bandwidth counter. ok, but if assignment is supported first then that assignment needs to have some configuration associated with it as to which memory transactions are counted, no? If I understand correctly MPAM would have hardcoded events (hardcoded which transactions are counted by current default mbm_total_bytes and/or mbm_local_bytes). The memory transactions that the event counts can be exposed in the associated event_filter file. User space can use the per-resource group mbm_L3_assignments file to assign the event to the resource group that will result in counter allocated and programmed to count those transactions for that resource group. With only one bandwidth counter it will only be possible to assign one event to one resource group at a time. > >> display the existing event configuration and if user cannot modify it return >> a failure when user attempts to do so? > > I guess it could. Currently in MPAM we just support mbm_total_bytes and so it > would always be 0x1F. Would we want some other way to indicate that it is fixed > rather than trying to change it? However, if we just remove the configuration event_filter could also be made readable only. This sounds temporary though and at some point the MPAM driver will support event configuration. I thus do not think resctrl fs should make big interface changes to accommodate this. > files then it seems natural for mbm_total_bytes to just have the same meaning as > it has when BMEC and ABMC are not enabled. I do not see a reason to remove the configuration file. If MPAM just supports mbm_total_bytes then user space can still look at its event_filter to see which transactions are counted by it. I am not sure about the 0x1F you mention (was expecting 0x7F), but below is how it would appear: # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter local_reads,remote_reads,local_non_temporal_writes,remote_non_temporal_writes, local_reads_slow_memory Reinette