From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 B881913D891 for ; Wed, 5 Aug 2026 06:06:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.17 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785910019; cv=fail; b=M3+BuXAzgiQ9lDnf8YjXSfbTJq69D4jzxz7EUJZNMuHD8tywzK5nzVLg+s8OKDUgRF8KriHnLgMjH3IpVBSxTxD824l0/sxbNGJqmOQGH5oqG5/hOa2jY6wOhN5iBIoW8sE9Uuj2df+Xa0YEMSJ7+w9kABgg9S8y1VO8bLcjQtI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785910019; c=relaxed/simple; bh=2QzDzMyt09b0Pb4+LkOo7mVlX4XuIKsYfDan8udhXd0=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=i3DVHAqBZmU/rX40VYPISXpyJJNQTUgf59cyuN9JOMygBH//BU9sEvfITOnp+He0BUOkpvDnDFo+1qapogqgX5jXbfIg+MwRNXRKV0MxtSGk7sCuhTPKyOb9a4Fon/nZDDdj+zgRdtZ7fOJcunD9nH47RYNpeU/ouGMwX+sEppA= 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=ctjajlY9; arc=fail smtp.client-ip=192.198.163.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="ctjajlY9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1785910017; x=1817446017; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=2QzDzMyt09b0Pb4+LkOo7mVlX4XuIKsYfDan8udhXd0=; b=ctjajlY9BaNLPp+9981EsbAZJjt127MnwaVQt+mV3k7kP5nEYORAIMmL j4C/IIYM439pgVQ7W/mi1wg5amThiKkHKLHXFOPr2I7Cz0TMWvybHYF8k IKkJh5bt+VgXqx2JNazUY5ciJJAwlNjeSuUCTR0HFI2c3xyf4pNBjm/lV zj7FZVccypXHrM4ks1Bfi2wqvKXCYW7K7pdW45Lvwbe/12Q2wfDWzZC+c LJzjZbTwH9tgvPfMNvMrwe0hUUzrIauPI2ddoTAkeMLA2yzvBsqgJhE1e oJIh1/wpF7huHW3GPKqAj/ybcOhapPdViVgUGhj40utgrKmMDMMhVNTRC Q==; X-CSE-ConnectionGUID: +CEBJexzT4CwMft9l2y5yg== X-CSE-MsgGUID: J7uYC2XLSBuURxowto+8Yw== X-IronPort-AV: E=McAfee;i="6800,10657,11865"; a="86353882" X-IronPort-AV: E=Sophos;i="6.25,205,1779174000"; d="scan'208";a="86353882" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 23:06:57 -0700 X-CSE-ConnectionGUID: +wYKAHzpTS6B11SteqYFww== X-CSE-MsgGUID: pUj267n4Ri6kUemrTxZcnQ== X-ExtLoop1: 1 Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by fmviesa003.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2026 23:06:56 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) 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.45; Tue, 4 Aug 2026 23:06:56 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) 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.45 via Frontend Transport; Tue, 4 Aug 2026 23:06:56 -0700 Received: from CH5PR02CU005.outbound.protection.outlook.com (40.107.200.44) 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.45; Tue, 4 Aug 2026 23:06:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=BbSF9GJSwWtzUYhB8uspCaCdYlSrYwq71W/QkBwFuOt7k0Kn9AswjiF9eHCnWZtD3yn0KyRGAKGtl9TjLPhZOH9LlwYr1ntnfajVm/Kg2HfytaE6YkgfyCp3qKSUPI0dn0HzNkndXGaNwPOucNMybOtKuFQVIQS6oqxUQ9LUHN1JrM1PM7niLfUVVA4IznfE9rlcsiXXNS3lS3rD66mLUY3UjzwJ+nJU+JlxbbWCQVcjvtCDpQEOnU3eq5k84X3Rt23QNKGmRLk9xibByK+pYgHD6a2i/PkeEIPxINfjMLXLhZDj007y6LJM7PBBQrdkWe1aMiFCBdiw3JVh5ATE0w== 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=64ruUGBZzvBJKa6ztjNkdT8S6rgnpbhTFtNjKq7YLfk=; b=By0ZYdbgtWe2suu+uW0oRgcVD7SXYkfR7LwwEPWl4Qk2gOB/t3iFW/RMt2Ky97xC1qx/OvibLzZXZQ22OElWzGK1PfMT8TI9w4NSrrLJhfhalUlVP8GqV92NEiCZgXDFw2Df6Yy/SyNFyUXgiCBV7YOroeRAyhRI6R1i/+uE5e6m+XoOOclBFlh2nDjKrK7s2JIXmbu/tIs2OVzSqMt/sLtPMT9ae+uv9AX0SxZTGGeQEkPs5LfAX2ER8UxiYLgQ/I1PDe4GU38KTz0KJG3t1ZG7JuacGrGbzmUlaC3nBHkWZpFlrO3zfo7CmxAtWm/S0QHZe8Asy5ab0lfYQs1zQg== 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 SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) by IA1PR11MB6348.namprd11.prod.outlook.com (2603:10b6:208:3af::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.15; Wed, 5 Aug 2026 06:06:47 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%5]) with mapi id 15.21.0270.016; Wed, 5 Aug 2026 06:06:47 +0000 Message-ID: Date: Tue, 4 Aug 2026 23:06:45 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Ben Horgan , Babu Moger , "Fenghua Yu" , Tony Luck , James Morse , Dave Martin , Drew Fustini , Chen Yu CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <36163a81-9737-49e3-93ef-6c392f7272f0@intel.com> <0fc6df54-26c7-43fa-948a-528cd94937f1@arm.com> <9049378c-699a-4155-b1e4-737a1d7265d5@intel.com> <57740b97-80ee-4632-bca3-dc43cd7776c2@arm.com> <44f26cd4-be79-476e-b002-7ccfb7705179@intel.com> <749bd904-523d-4e9d-8493-0e8cfd79949e@arm.com> <9db33feb-cf04-420c-a99a-e31e4b8e4954@arm.com> <8fd6caed-820f-457a-a1ef-a0a006fa52aa@intel.com> <4ef15dde-2fbb-4763-93b6-4333b02d6859@arm.com> <7b751c28-2f04-42b7-b957-af6447e7f824@intel.com> <34b95afb-8b60-4680-9ad1-90c5b24e8fb7@arm.com> <08f016bc-2ba6-439e-bb3e-20061166402c@intel.com> <21e614b8-50fa-49e4-87c3-e6bdb4e83ab1@amd.com> <653c9a0c-c665-4016-90b2-3f55e06050b3@amd.com> <618ba724-d734-43d3-b90e-11ba7f31c2b6@arm.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR04CA0157.namprd04.prod.outlook.com (2603:10b6:303:85::12) To SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) 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: SJ2PR11MB8370:EE_|IA1PR11MB6348:EE_ X-MS-Office365-Filtering-Correlation-Id: f09dafe3-8dcf-438c-c1db-08def2b7bb9e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|1800799024|23010399003|22082099003|18002099003|11063799006|5023799004|4143699003|3023799007|6133799003|10067099003|56012099006; X-Microsoft-Antispam-Message-Info: 6Z6Ou088UGcUwVPyv3+gslTj4EHE5TmUbAeGKFkuHdaGhOQCgna59tRe/fUYHvcZ+9G6jE3iYBf50ztyMr4u0AO42FJQdWljOkKRGvJU/C6YY9T9d1sEJkMV+4XPQexClRH4b0ebvjeU7dk2EMMnlqfJyri7sCIxAOIvqMbKZ6vipFz7PeRgqy4Xm4wsSGlkRq4PgaYtS/97AlBYPTxo4Kb5wTib1spJRLoTMdXUct1SthD4zxJzVu5KqJPRp2C9IOI2E2W41DLzio/mes0M8t07DWItevhL2HDhPk60BGruKPPi8jDEMWYkfUOmSLd11jeKi7QkpUTaD4SR9xVYdgyfsM0YI47nck1EZsvaQL39k0FuD/OQ8u+91hfcYwtFkZD7zar5z157IOTctJEx5kqhQVJEFWxe+vVQaGW0wO3h0m/G1gRnxRJ91R6IEuuL82Y8+2wy1n9CF2N7PleVLTzKlz6dw4G747XKQ2eSdDzOq/o+Fcf+e/aDgImJ2Yp08+ujhPRm7FToyLH4oJv7d3+fl8MLJXqPDMpcfvrJRaiFvPy5f49U3eoFsf9nGkMEFW8XUcQDYDj+KX3keO3Vq/EUy9rx7u2ZR0vcMSj8/yM= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB8370.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(7416014)(1800799024)(23010399003)(22082099003)(18002099003)(11063799006)(5023799004)(4143699003)(3023799007)(6133799003)(10067099003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M0NvaURycjJ1d2dTa2dWNUNtazRuM3VZa1lkdnlxcENTbFlyU1pTNXFsRU9t?= =?utf-8?B?dFN0aGVvVzdDdVNSQXJwQVpoK3BRcm9BemNIdG45U3FEVzdLR1lsWDlhN1Bq?= =?utf-8?B?cFpyUlBzZEprR0Z4cVdoZUh5YjhXYVcrREo2YkFWZW1ldTZZV1pqQU1mTkR3?= =?utf-8?B?Vk5IWjc4WnZIWDVJRkVTUzhsczFBYW0xUExCQTM4N284aDdXLzVXL2YxOHNj?= =?utf-8?B?OFZPbDdmYjBvVUVhY3VPeGgrem90NlJEblh3czJtM3ZTVGJ6OFByVWZMeTRy?= =?utf-8?B?em40cUpWTDFocDNvTzNyMTN3UlhsZmEzQ2JjOGwrTVdab2VmbElFMG9qLzBE?= =?utf-8?B?L3FxTjVjYTBCY2doblNVSkFhdTd2OG1wcW8wbWhQY3ZnUUlKNVBlbWxlaHVB?= =?utf-8?B?VVV1aEFwc0gwZmJ1alBMMW5wbWE5d2pVMHNJRmRuTnNvTEd2QmxHMmRpOWUv?= =?utf-8?B?ejNEUVhDamJ6NnFQTGovSTFsYm8wMTN0MGVnb3NTVnNDZ3UrTEZPcnQ5NWtR?= =?utf-8?B?VnowYjBKcERobStWKzF2UVZucExVemtUbS9la2RFazd0V0lNMUFjZGtBZnFX?= =?utf-8?B?aGhscTdMM0o4OHU3UzVhSmRUTHVmQkdkSkVZankvZHNMOFRRZGtoYXlwVk1V?= =?utf-8?B?TksxZzU0dE50RkZ0dENYZTM1TXBpeDJvMmFHTERreDl0Y2E2R2t5RWR2NDdI?= =?utf-8?B?QStSU3BJdVBWL1dJWWlXZEdJTmdmYWhjN3NsbUtvdXBna3BJVG00QXZ1SzVT?= =?utf-8?B?SVJDQWJ6UXNJWE9WR3dveEQwYmo3VUx6TTVXUUlHYzR2QTZUbWpFOVJQQUlN?= =?utf-8?B?N25UbFpiNkx2VnVjaVpFT0psT2JXUHV6TTlpSzI5bXUveUhCc2JTZHdXcExK?= =?utf-8?B?WnFXMXliSHEyQmgydGtZVWxReUtQbXI5YWpGcklxNFpLTnZESkNid2dnd3pu?= =?utf-8?B?S3ZXTmZILzBnNHFGV3RJTzhyeUZ3MFFIdkMzL01IOEtqNGJlUUpaZlNJZ0N6?= =?utf-8?B?TXM3SU16Ukx0YWFyeUJOTHp1UEUyMDJnSmxQUzdtZ1NDTWpKRGEvZEM4OFRj?= =?utf-8?B?cFJ3Kzk4b0Q2cDJrWVNxUjQ2WWltWnl6MWJGdm5tdGljSmZFRjlKTDM3eWgz?= =?utf-8?B?ZmU4VFdhUXVWZzQ0cEw5WmpqMCtPcThoWVp3WTAzTGZMKzFhSWtMUSs4MzlI?= =?utf-8?B?Lzc4dTdLQXJVakRyVGNxUHgwMGJOSFAyeHA1cUlxdVM0QllEWEZaWHhnZGN4?= =?utf-8?B?VGxvLzRQSmFPUnpCeXZFWUYxSC9WRVhCR1JIVmxMZG1uQkN6VE5oMHJFZ1Y3?= =?utf-8?B?Q1pRSW1VSTJ1T3grRmN3WFV5SVFkNmVDN2UxVkdXcFRHd3BpSmt3YUh1MHIv?= =?utf-8?B?OUlnQ05ac2U4WWFlUi9ZRVdmWUFmaFIvcHphUFE1K1NhVDJyK2NpK0EvM21D?= =?utf-8?B?Vng5cDFFbk5jeFd4ODFZM1VhVXV1dll3SEhXY0VtT05QKzNIRm41bzBGT0t4?= =?utf-8?B?cW94bGN1TVpyNTZldlFRTi9wSjV0akFGeUVkNFN5c0VhSUVTdEZqNUppZDJm?= =?utf-8?B?TzlEajlRd29FMGdjdzVGQ1hEaURmRE8wSHVnWTYwUEQvaHpiY1VrcDdYenBk?= =?utf-8?B?OHJsSnNRcnU5dGIrUWNRdlNYV2xSZXY1Tzh0TXh4enV6ZXVDdnRGNnlwTDVn?= =?utf-8?B?NW9GU3FYM0s4eTZpbG5EVmtQaGRoYW5FY05SZi9teG1mQzlPT3FEc2twRU10?= =?utf-8?B?dGpmaTlQT01sOXgycnZmV0NjeWJPNS9NRzZFeEFwZVQwcWxVZStRREVrZlpw?= =?utf-8?B?Yi8zTFJCNFRDVkR3Q012b3FYcXVaVExBOElmbnJnSGR4YTBMSHRzb3JJZTIr?= =?utf-8?B?MG5OVnlkVUtTQnlGVlUyaVZiWWxJWHpuOUtzZWN1QXRJSmszOHpNWXFtVXlR?= =?utf-8?B?Syt4QkxMY2Q5T3M4eG1LeVFvVkRPMGRlYXhJNWhZN0Fmd2htVzZ1M2J2dEFp?= =?utf-8?B?OHo1dU5IUE5kSXZvSXZJRXhMVHAwRjRYeHNXTG1DMjYxek9JdDNia2RWRThz?= =?utf-8?B?Slp6OWQ1a1lwZnB4VlhJN3ltWHZ3OTJUbllaM0hVUnBlMHcwd3pKdzBVVit2?= =?utf-8?B?QjJjYlhUV2ZqNDl6NGROT1UwRyt3aUFOMzlNOEFuNUpFUnBTdmxwSFlHUWRW?= =?utf-8?B?ZjdZbzEyT1MyWUw3NUVZU21sZGRHRkJwSzE1aGl4dmtmeFNvd296bEUxcWdt?= =?utf-8?B?R3g1dEZLcmFSM0JjbldZSHNxc0wxMVdRRnpJa0g0SUx1NTRrVkJXeDgrUVE0?= =?utf-8?B?bHhpdm1uNnNocnp5Q0d3dGoyalpDcVRYbmIxZ3VEK1FYTUZFcG5yUkNVbjFE?= =?utf-8?Q?pAox20APtLQ69r0k=3D?= X-Exchange-RoutingPolicyChecked: m253K53sqRq4Bs2jMC1JbgqP6ob6T1aiPD7nAwgk754/q1x3VaJ2Scih0S94+/MjJpihn8h6yYgIS4Y9LaRe/xY0EPfPmOtQT028Y3x34vejZ4uwHSVaiIeJnwe5i6gIb+MPz8dJy+jXttMhuBc3O70r1FcNd5hcJVZ43lrvSUwpBrmiTYrfoKTiJ3Dfm0JgYSpRrMqfXBCfpCT5GybhfnhsBN77H/nbm2fUzL8hzus+WNZIa4L2mgqJQItX59Is7v0z7q5d8ESb/xnKZS835ewIT2wcixtuEebPOvc6ILWFQp7PydkqkzcrxGf3e6dfBGo2sec8nzB2Iu+A1lTFYg== X-MS-Exchange-CrossTenant-Network-Message-Id: f09dafe3-8dcf-438c-c1db-08def2b7bb9e X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 06:06:47.5498 (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: UaPnSv1LzYrTYq4Q7GKCLnU6XRojyxmmGnsczFndSNC77z6C1TIgXEjJotia5pV1+VhMLs2xcHlg4eiTZ6yOZciz1CsuaQDhS58UgXjtmdA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6348 X-OriginatorOrg: intel.com Hi Ben and Babu, On 8/4/26 8:11 AM, Ben Horgan wrote: > On 8/4/26 15:09, Babu Moger wrote: >> On 8/4/26 04:11, Ben Horgan wrote: >>> On 7/22/26 18:02, Babu Moger wrote: >>>> On 7/22/26 05:47, Ben Horgan wrote: >>>>> On 7/21/26 21:02, Babu Moger wrote: >>>>>> On 7/21/26 12:30, Reinette Chatre wrote: >>>>>>> On 7/21/26 6:23 AM, Ben Horgan wrote: >>>>>>>> On 7/20/26 23:54, Reinette Chatre wrote: >>>>>>>>> On 7/20/26 6:30 AM, Ben Horgan wrote: >>>>>>> ...> >>>>>>>> The former, info/ contains a directory for each allocation scope of each resource. >>>> >>>>>>>>> >>>>>>>>> The other x86 feature to consider is AMD's upcoming "Global" MBA/SMBA that exposes memory >>>>>>>>> bandwidth allocation >>>>>>>>> in "groups of L3" that I understand could usually be mapped to NODE scope (but it remains >>>>>>>>> controlled at L3 scope), >>>>>>>>> except for one configuration where it is "SYSTEM"(?) scope. >>>>>>>>> Ref.: https://lore.kernel.org/ >>>>>>>>> lkml/8f77f498b1c77fa8fd8f5d5687f03ae598068544.1776980182.git.babu.moger@amd.com/ >>>>>>>> >>>>>>>> Hmmm, I'm not sure that the scope can be considered to be NODE scope for GMBA. To me it seems >>>>>>>> to be >>>>>>>> accidental that it maps to the NUMA node but really the scope is just a grouping of L3 >>>>>>>> instances. >>>>>>>> For a control to NUMA scope I would expect the resctrl domains to go offline and online in sync >>>>>>>> with >>>>>>>> the NUMA nodes. For GMBA it looks like it would just going offline/online based on whether >>>>>>>> any of >>>>>>>> the CPUs and so L3 instances in the group are online. Am I correct here? >>>>>>>> >>>>>>>> Assuming the domains are on L3 groups rather than NUMA also changes which end of the link the >>>>>>>> traffic is regulated and so how cross-NUMA traffic behaves differently. If the domain is an L3 >>>>>>>> group >>>>>>>> then a task running on a CPU affine to that L3 group won't be throttled unless that particular >>>>>>>> domain is throttled but with NUMA node domains it may be throttled if it has traffic going to >>>>>>>> that >>>>>>>> domain. >>>>>>> >>>>>>> I'll defer to Babu for accurate answers about this hardware capability. >>>>>>> >>>>>> >>>>>> To me, Global MBA should be considered a NODE-scoped resource. In some configurations it may >>>>>> appear >>>>>> as SYSTEM-scoped, but that is effectively equivalent to a single-node encompassing the entire >>>>>> system. In such cases, there is only one schemata entry controlling the whole system. >>>>>> >>>>>> Yes, multiple L3 instances are grouped together to form a NODE. Internally, programming is still >>>>>> performed at the L3 level, but that implementation detail can be hidden from users and does not >>>>>> need >>>>>> to be exposed through the interface. >>>>> >>>>> We seem to have two things that can both, somewhat reasonably, be called NODE scope in the resctrl >>>>> user interface but the behaviour required for an MPAM system and an AMD system appears different >>>>> from the point of view of lifecycle of the resctrl domain. >>>>> >>>>> For MPAM NUMA scope the MSC instance (MPAM hardware interface) is at the memory controller and so >>>>> goes on and offline based on whether the NUMA node is offline or online. For AMD NUMA scope it >>>>> looks >>>>> to me that the lifecycle of the resctrl domains would be tied to the CPUs associated with the NUMA >>>>> node. To me it does seem odd that a control with a domain associated with an offline NUMA node can >>>>> continue to throttle (cross-NUMA) traffic. >>>>> >>>>> Is there any GLBE Control Domain ID or similar that is exposed to the user, e.g. is sysfs, or is >>>>> this just implicitly the NUMA id? >>>>> >>>> Yes, the GLBE Control Domain ID is exposed to the user. It is essentially equivalent to the NUMA ID. >>> >>> What's the on/off lifecycle of these nodes? Does it follow the NUMA lifecycle as managed by the NUMA >>> node notifiers documented in Documentation/core-api/memory-hotplug.rst or is it just linked to the >>> cpu hotplug as is done currently for the resctrl cache based domains. >>> >> It will follow the CPU hotplug lifecycle, similar to how it is currently handled for the resctrl >> cache-based domains. > > Ok. MPAM MSC are associated with the memory controllers and so MPAM controls that have NUMA scope > will follow the NUMA memory hotplug lifecycle. This points to them being different resources. Do you > have any thoughts on how we would handle this difference? If I understand correctly, on an AMD GLBE system, even though it is "NUMA node scoped" it does not support memory bandwidth allocation for a NUMA node that is online but all its CPUs are offline. This is because GLBE is essentially L3 MBA that allows to set limits across multiple L3 domains. I think this is a good match for a control associated with the legacy MB resource that just has a different scope of allocation but how to do so without creating confusion with a "real" NUMA bandwidth allocation is not clear to me since it may end up looking like: GLBE (make clear allocation is at L3 scope but domains are node scoped): info/ └── MB/ └── schemata/ ├── MB/ /* scope of domain ID = L3 */ └── MB_NODE/ /* scope of domain ID = node */ MPAM MSC (make clear allocation is at node scope: info/ ├── MB/ │   └── schemata/ │   └── MB/ /* scope of domain ID = L3 */ └── MB_NODE/ └── schemata/ └── MB_NODE/ /* scope of domain ID = node */ Any suggestions? I do not see how these can be considered different resources though. To me it looks like different controls operating at different scope for the same ("memory bandwidth") resource? Reinette