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 EC8C83E1205 for ; Thu, 5 Mar 2026 17:23:08 +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=1772731390; cv=fail; b=V7cMlLpInFnBouf82clxYBghUQLz2tLzQKLvvlEJBV+oBLrzvgNun8wM5jxXr8izMJiN1zfUY5HhpjiAyZX2Aotlci8s9IjkW/yMRFjycVPG7kE7oixoRG/2hUaTRYi4j49yi5BVqzfalFtvqVfRppyggPwJsNcKqNW0x6A/wkY= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772731390; c=relaxed/simple; bh=P0PQYNQ7UHvM8HAoKg6yejwXEYVx4r2Vlwp60rKZjpU=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=uAHqglnL1omNWgLgIjagwGyIyMxNh5osHzd9hSv5TbqW+YKRCZD7Mj0VYqtLJ4684ru0+xuswfdxWrhB3x5B54OPr026SmBpTqdArWecMCy0OSIB3MAe4Idju2IOI4CiXDVUvUWHqy3QetIT8Wa+0BstleLX59qIQZArTmU3KrM= 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=K2kZLf7g; 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="K2kZLf7g" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772731390; x=1804267390; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=P0PQYNQ7UHvM8HAoKg6yejwXEYVx4r2Vlwp60rKZjpU=; b=K2kZLf7gAvq0M1s2IWnVSr1+mZKoA/hfkeYosXR1wmhtjQ47EcdwPTNq lqT10bzHWl4zWievvuK+wQuAZxXhaJi9DHyfYCv13hIdoP8CQL3/bCYzF zLnTQZSki16tLXTymbUXSRiEY4Y90nMfbp7MqC5l323q8IWwaZ1twc7RC 98YtqLW9/tkG9fi69Xg60CaAN5A2rnfIFB7IR85/djzWFwsFRS5z7k+wT J78VXSmGUGc8SlmFVKMmoBJR+YBOp4LRkTbfasjio7T+ysZ84bkIm8OWT a3vgzJUJZDdbys6i053ZPpZ1xcxEjUIsLuBBJOU6q37NkYiswbzNYebhU A==; X-CSE-ConnectionGUID: EspzsY4cSX6eGMT8W9ePbg== X-CSE-MsgGUID: ysbDWsjzRb686kVvhrtR4g== X-IronPort-AV: E=McAfee;i="6800,10657,11720"; a="73795992" X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="73795992" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 09:23:09 -0800 X-CSE-ConnectionGUID: GTRj1N7PTbaxB7SLDgZ9uw== X-CSE-MsgGUID: +Kyu3AFTSTWGN95v9xD18g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,103,1770624000"; d="scan'208";a="217008786" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by fmviesa008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2026 09:23:08 -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; Thu, 5 Mar 2026 09:23:07 -0800 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) 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; Thu, 5 Mar 2026 09:23:07 -0800 Received: from SN4PR0501CU005.outbound.protection.outlook.com (40.93.194.57) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Thu, 5 Mar 2026 09:23:06 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hpPUiOy6dBpNtGiREOiLuunFqQCAN5Z8yWvnbfdVyTPgaMVi2Ha0RpXgknaXoVCUw1o1AJ/eeP687Wpt0Dn9wiKteu90mlN5wCw5MqgaLHHLLHZtIEuSb0KldViVMa4amGxeVP74SyZ4tMOJhHfqaoJBusc1K5G6fWchcLmntcNTjIgsrpRbACtFJh1Tsn1i1Evxd98JHbxM1xSFBU9wzir/nel8F1uogivV7LsR5Ppq68OzFd/Fq3V3Zmu4P4uqBKk724pZoNHRmYBO+ac3iU/tea4kHO7iYlWNeBMzPtcWARGECjL1xAMWt3ZtfXDU3qCk3x8xJLd064Zm7ukjjQ== 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=mASI6U16dLEc6fTHXs/mz6hwGlRbyYEfqdAmGGJu2TU=; b=GJZkWmMSv1GZabRT0PuUJveuHN4D1oQyqC5KwapmcinXQ3akMd7C6OrRSitNvl0zJNxg62k3wWRRK8GD11g3CppoROpCjqckAaypGClypRmC3hBtkNRb9B/oZ5tEfNT0DHHBvtHKLtTp81SGuFeCzwjwbWEB/OytSQt7hUWWSfbWjKrRDLcucveiogDdPX130GITOOoGvIbTWQGrA+a9OuJeFQuGcX6tjlDEvhAxNexUDMJPnJGvegBG0A8TwtOEIjS+0st9CgZcf0miiVnaZ8iPE5nn0eET+BIezYo0U4sXFNDeUG9FCkSiNSkca5esBeTuURIJY8S6+kHbMhGlcA== 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 SA3PR11MB7625.namprd11.prod.outlook.com (2603:10b6:806:305::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9654.22; Thu, 5 Mar 2026 17:23:02 +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; Thu, 5 Mar 2026 17:23:02 +0000 Message-ID: <940210db-1447-4a0e-8605-a3e83989afb2@intel.com> Date: Thu, 5 Mar 2026 09:22:55 -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> <39b9c59f-e001-4733-9afb-c9a0c7f279a4@intel.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW3PR05CA0004.namprd05.prod.outlook.com (2603:10b6:303:2b::9) 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_|SA3PR11MB7625:EE_ X-MS-Office365-Filtering-Correlation-Id: 6e104e5d-fc17-48a6-2a02-08de7adbdaf2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024; X-Microsoft-Antispam-Message-Info: sRY5lK+WA767fVEy/WuhBktwa6d8yufruuNfybmEgMUJVKApV+NP4Oagy2j53g9Zp4JdsnW30sX6aQHVjViYOnpnkxfsu8ppZcKgtCkYAt2swWHa7cZrMIIe6AgLJelBrSzns82VA+ySMjyhoFgHc86CXrma4fnqtRPhB80fSFj0MLr0mIuxWLljLldvpkhOs2++tMXhGa8AiiNJtZaeRSNxxB5oA+8ztZynRtVGhyVITj4udHaXhMPy/f6Zsfb4QkADzZk7hgM93k3yboWCVtxAo0K9pxphU0tjYlOYA6gpxEMWfs/y64ArM64+VaovIqA28uVSjH7SZOGAdvfvIEmPam3d7PkJbdjKXLzhIPm4E4a1fkRvoA3y4mBfoCU+Op35V4wiwHEUmx9SIVofaeAssUcDhTavKFu8NCyr+gTI7tyhJtLhA60bbnFNvdaJxYXgEtw0FJUkkQVjslJY9GUSzCnp+zG7PE8N2ip53457O4u0SV29fhJqphyztjQW/cPDhnCg7pse8d1KPH43S18/N8atBrKyczATzvYCHeUq50EcExNGF/sUbM/tqwwXLP2DGVdDk4kiqRx7vf7zgt1Fx00fhEu9pSh2JRQp6R5UDM8AtBrfET2KiGC8Ve41v0YawANRDHhlZRXq/7XfCHDkoPQA3/ZeBbeiM4LJ57Xyp9m0azdsXX5KNwLCZgZWQZLer298YNfl7SH/qIf4JNPOrBcXWLb4sPpd9Qawg10= 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)(376014)(7416014)(1800799024);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q1BKQVZjOFhSRW1qSCtLdmVNL1VuWFFReU5VYmhidzVNMVhXb0NLVG5FRk1i?= =?utf-8?B?N1BZUmlOMVRxUTJWamFkWDlJWGo3RWhYUU1FbjB6RzJkazFGT1lnSWRYOXNO?= =?utf-8?B?KzArdjZpb3NrbzRXcnZiZGdxdkV0QXNGVjNya1dHZUVsRFlPRzROV0hndzZB?= =?utf-8?B?YnpNRnZUS3F4UWN2b3F3WFhiYlZrZy93R2xqYVZkTEd5NlRVVkcyWW5DUmhm?= =?utf-8?B?NndFMEMrQXVZZm85eHR5UjNrR1l1eTRraWlrZWd5alEyYlBLRU5RWEduU2Rs?= =?utf-8?B?QUtleGJGQlE2bExrUkVSTUtLcnNjaUtrZ1VNc1NuV0xhMVFDaHU3K25wR1Rk?= =?utf-8?B?R1JzVDljNTZ1VGxhSWhSeS92VTdhUHB4V2lHWWlrcnhCNXhCWHQ2enFZOGRt?= =?utf-8?B?S045cS8xbmJsL2t3UFVyQ01ud2VIbWlZQXhpVkhxZ0orN0VQTE1CVTR5VUNZ?= =?utf-8?B?bERpNGsvRTN0VnBHNzgwRTc4eVkxeDRMaEhUUjJYbDlBWDljUTIrOXJaWlNt?= =?utf-8?B?a2tUNTdUMnNnVkY4bzBrMHBtMEdkTXBKR1JXWmNSOXV0azdIUXYyakxOUGp4?= =?utf-8?B?ZFlJcmRpWDk5TkppYUdjWjlHcUUvSFRUR2hVRHNMaWdnQ1dLemsrQzhNZ1RQ?= =?utf-8?B?S1p6S0dTdk5HYitCMWFvZVFHQ3VEaVpKclptNHVFd3o1S010TVVrcFJiYzBT?= =?utf-8?B?MldZZThVdXhhd1VQVUczcHhOMEs5LzhhaFRNYnRQbFFuRmNQR2hDZStFR0hY?= =?utf-8?B?MlRZQlVSMnhJQkxvRHFlTmtKOUJlNU5ZU2JHeCtmakR1ZnR3WDFXV3MxSDJ0?= =?utf-8?B?cFdheXpXbFI1ZjFTZ0VPbFhvUmE5OTVVQ2pQR2JRZ0U4cFBpUWRpZTIxZDl1?= =?utf-8?B?YTRXZ0dRbUF0SHRHZGRhZ1FjMDJIVzJtY2J2ek9UL0xMZ2Mva3R6Q04rS3ly?= =?utf-8?B?OUVOTEl2Y2ZLVVd0RTZsM0tGYTY2dUZOcGRKNDVMS2s1RUdDYy9EL1B0ZW1r?= =?utf-8?B?RGY1SlVrUTNVMEttaERWcEQ0OXk3NVF4a3lDa1pWWDIrQXdqNnlhSmpkd3Er?= =?utf-8?B?bWtndm12SDFyTHVkSHFwSlgycnlkd0V5RHdtSXQ5RHo2Z21FZjJQMTc3YzVz?= =?utf-8?B?dUl4TE5zQXdaRjhudGtJSkkvSlFyejdYNXpjUVF0aE00a2pRalhxbWRnUFZt?= =?utf-8?B?VFlKT3NqYlVXUG5jdTRONWlpWXdIdFptaXJ1NHdsMVRPQ1Y0WEhaUTdqdHRn?= =?utf-8?B?VDJlZFd0elJUeUcreEUyQXZHTkw4ZjFGYlI3bkEvSitDYmpqNWtOa3gzUStn?= =?utf-8?B?Ly93ekN4YzVSc3FvZXB1d3c4UGoyWGs5U1VrRjNWZ3hPNmE1SEdiNlkxV0hT?= =?utf-8?B?WHFTZXU3OXBEKzIwMTZFcHpmRWtDWnEzRHRJZ2grTmQxT0xyMndFbVlZZGEv?= =?utf-8?B?MXpCWFF2K3VqcnhEN0U3RVZDRGJBTmR2a1BrOFpSUVhsS2hCTjF6Nks4L1dG?= =?utf-8?B?bTJEU3IxNDlUM055Y1FwTng3b0Jaa2xjVUpTYVIxOU5KZDBUR0cvUEFUWGU0?= =?utf-8?B?MTFKWHJtZ1NHTDZNK3ExZU9oS1gvWlp2NWFxK0xoTzVYb0dJTmc4QUl2aFQw?= =?utf-8?B?blVjN3d6YW55S0xaWkR2TTZSTlczNU5oK0ZabEJ6eTlOaWQ3aEUyZ1FVRXZi?= =?utf-8?B?ZklBWlpDeGE0a29iQVFoZW9vblFQYlZGUmZXdkUyN1RSZWtQK3J0bWp1MkZn?= =?utf-8?B?STlJQkNMZGlGVFBrQW93NTVRY1V1bkRwbUVlQWN5V1huQTRITDRaVVpjdHVq?= =?utf-8?B?L1lYc3FEVTFYVVorc1YrSmtoTUo1VkQvbWFwWGg1NHIxczhmWUhZZU1tM0Fr?= =?utf-8?B?Q3Q2T0VXV0RwVGdkTS9jbXpFb0FXaFlZbWF3czRNVStCd0JEMVM2UkgwL2ZZ?= =?utf-8?B?NUVNdElWdW5RUTArV0Y3RDZqN2Z5WEZnUTNxQjUyU0gxYm9xRUtFQVJacmpD?= =?utf-8?B?N1RaVWtUWlI3VjRieXZxWHhJNHBMcHlKTXdxanhaNE9sTEt3TXVsVTVIZ1gz?= =?utf-8?B?TUc1aEZDMElzZUYzK2RkT2ZHUG1OWW9ZVGJnSmFRSHBYU2JZVVo4YnFFZFl5?= =?utf-8?B?RkM3MGFMVE9vV3BWTjR6dk1Qc0ovclU1THQrSU1OODl3RGw0cTV4bUt3ZHox?= =?utf-8?B?RXdFRUpxN3pPa2Q5Z1d1M2k5bi9wNmhhc1RpMTdsTVdMc0VHWTVPTGY0UEFw?= =?utf-8?B?QkI3U1hqb2pUUTdJenpmbVBwVDRBQVZ2OFBNOEllT045SWU3Y3ZqaGNWSkUz?= =?utf-8?B?T1hKWmlLM2VlaGlwUzBCMUF6QkZLNklKaEtnR25EU3RyTTlhckIyQXhmMm5a?= =?utf-8?Q?1IDcIPbMtV5DByPc=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 6e104e5d-fc17-48a6-2a02-08de7adbdaf2 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2026 17:23:02.3861 (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: 8dlTQ3RNN0lFIlDe7UCOxT8esCMNWvU3xRpNituDgKniz0Kc2w651+ZAzq2wMRFA4PiveCkrsHYPdarwmO8mA+WevdhrLq/D78ojqnqxtnc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB7625 X-OriginatorOrg: intel.com Hi Ben, On 3/5/26 2:01 AM, Ben Horgan wrote: > On 3/4/26 22:50, Reinette Chatre wrote: >> On 3/4/26 1:01 PM, Ben Horgan wrote: >>> 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. > > Indeed, we have already weeded a few things out of the MPAM driver for > similar reasons. If we start with mpam only supporting a > non-configurable mbm_total_bytes with ABMC I think we're ok. I'll drop > the non-ABMC bandwidth counter support from the MPAM driver as even if > we've got enough counters, one per (CTRL_MON/MON, evt), we can use ABMC. It sounds like the expectation is that when there are enough counters the user will then run with "mbm_assign_on_mkdir" set so that counters are always dynamically assigned and thus essentially be "non-ABMC bandwidth counter support"? Since "mbm_assign_on_mkdir" is set by default then user space should get sane behavior by default. Alternatively, a user space would just always run with "mbm_assign_on_mkdir" off and have full control over monitor assignment even when it is not necessary. Sounds good to me. > Also, when event configuration (read/write filtering) using user defined > (or new) events is added this will mean that enough counters becomes a > higher limit. That will mean that the software controller is not usable > but for now I think we can just fail when that mount option, mba_MBps, > is used. Later we can consider using non-ABMC bandwidth counters when > the software controller is requested. ok. Since info/last_cmd_status is not available to to user when mount fail, please do add a message to kernel log to help diagnose resctrl mount failure. > >> >> "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? > > Yes, we'll need some finer grained control for which sets of bandwidth > types can be configured further down the line but going with read-only > for when there is only one fixed set seems good to me. Thank you very much. Reinette