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 ECDFF3B2FD0 for ; Fri, 7 Aug 2026 22:53:33 +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=1786143216; cv=fail; b=qJJNP7LNA23JuL0oRxwVE+l3FeYNHOvGFwZpIv7onU+XLmsNHLyu7Abwd9qo4D2YlEQYgy1D+wmvtHUImiuFCq5sfdvOC56REr28+PF+dE6MVkPtzgU+bNxMkv/U/G06bmJFsvtneovNM46YOehpTf8hwhth0jQW6bXFUPnuA0Q= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786143216; c=relaxed/simple; bh=sRG+eq1HUFStC8VKTCqMmn/IBuYrJgGcFhB/sekPiHM=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=s90cUvUVEeNgQDYhv8BJ+4sjDstn3NzyySzeI9ixGrGRIcGoW60MuXGvFoOgTnAB/cQrORRGvLqsAw45vloGJrUZJNO3TExY2nJBLviC0+4AbL9TQ646SIMttuZQM+4GGCgcwexvFOcV2NC/kMMqdolMS3hyy6U/yIRtIDu3Hh0= 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=b9MRvIBA; 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="b9MRvIBA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786143214; x=1817679214; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=sRG+eq1HUFStC8VKTCqMmn/IBuYrJgGcFhB/sekPiHM=; b=b9MRvIBATey641rpIhh0Vu6P6+4od2OsxYrg9hUUYOMOpzxvRqc25P5o DHIXpgUTgBiIUa+09lVWSefBTO40iMg1uwz2bqMrw1wxiAo5T0fMSAz5Z ZyzL/q2qORERtCDqeHZ2LseLU2Tg+hJGZpEz2Uhjk0XS5on1jCj6OEoWd ht8y0TfGVEQZT49Qak5kzHs0SDXIVG3f2QlT7/hTtzabewpYpJKTw3c2x BOnvYsSVLMxzqpnZRWtTysFahVeyHYe/0Mq9su83AoeruZ8HdKtm+WDW2 j8TnOumeDNwiZ1kiNoGM6DWAO49PJhzL59iUHN56wPmR5Id4AGKf10QsS g==; X-CSE-ConnectionGUID: mSAYEiokQuGHYikPCoDSwQ== X-CSE-MsgGUID: 4vWhZpo1R82goTEm40Gw4A== X-IronPort-AV: E=McAfee;i="6800,10657,11868"; a="74295952" X-IronPort-AV: E=Sophos;i="6.25,210,1779174000"; d="scan'208";a="74295952" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2026 15:53:33 -0700 X-CSE-ConnectionGUID: stCIR9OYQhOG63EYXCDYNA== X-CSE-MsgGUID: kTQw03JvS8+eu4xN0wsfuQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,210,1779174000"; d="scan'208";a="300727804" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by orviesa001.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2026 15:53:33 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) 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.45; Fri, 7 Aug 2026 15:53:32 -0700 Received: from ORSEDG903.ED.cps.intel.com (10.7.248.13) 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.45 via Frontend Transport; Fri, 7 Aug 2026 15:53:32 -0700 Received: from BN8PR05CU002.outbound.protection.outlook.com (52.101.57.57) 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; Fri, 7 Aug 2026 15:53:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lIPemz3Sv8TajkmX2glNDKt0LbKaLmiUSKMrcNylxq0FYoFDm5u7Frm8zi2RJpFVl0nRUJsumw2Pu+XZI2MRFXw81SLMz2fyO1LD1pnWNP8x7EmqseupO/E0TYeOv0f02STm1NNIr52dRS7+5ufGDCy02RgOipjzYeGkiW4bTDumHsP23aA0u9D+3kQzMgbLT5sOdubxZ5dTwBHqUb9gmEoYb2GWQY5v8Mpg1nObbMfpU3Vfr1PTV6HFGDt4uWlePuLRFd9ccWq05lWAmOvmRZ2xmd+AIv3hFwvCPq/9RW9I9tJPFgAE1OaG1+i+qBZ9swnjxIdzHsMcyAOpui6sJQ== 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=MZlIR/QaL3f8dJzJbBfDSleJjuXkEqzOKif3CSsSLJI=; b=Z8BWOiGZqFmLZnk6VU2Ga7SLuKCg644jLQu+PwwdFPd8CPCNRVTztBbNPEnaj6T/zhxUzaNvkhdbSa9ldfITNQvV90eWkoQMHbTvW+yI0iVPA0jt7tda+/W7W6sbRiwyCEo5jLzkyuPzX4kSCz1HwNWuZ6GzT2YHiA8jMFRzOGqs/qGjxltu/EQ3KXSY28ygu8RAF47h5CGiTeVZdxBZLEaIYV8Tfkfzlfz+Wn7yalZasQi/i+HZztdy0axzzRWcfzHQYs56stCXda8xtWb6xZm+OV5aSDcVLkQ+XlOwmR4fLITlD7NKP26YoBFkpgNpw3CetpXLoytOTYv28QGoUA== 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 CH3PR11MB8382.namprd11.prod.outlook.com (2603:10b6:610:173::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.20; Fri, 7 Aug 2026 22:53:29 +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.0292.018; Fri, 7 Aug 2026 22:53:29 +0000 Message-ID: Date: Fri, 7 Aug 2026 15:53:26 -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: <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> <1444b515-752e-4167-87f5-30ace189e05c@arm.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <1444b515-752e-4167-87f5-30ace189e05c@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0198.namprd03.prod.outlook.com (2603:10b6:303:b8::23) 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_|CH3PR11MB8382:EE_ X-MS-Office365-Filtering-Correlation-Id: 15784a38-96c0-4aef-47bb-08def4d6b2ca X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|23010399003|7416014|1800799024|366016|4143699003|3023799007|10067099003|56012099006|5023799004|11063799006|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: DVkxkeyU7QblKuoUCCURGQ5wD/mSnUZQeh6FxJgY6p0nc2SSLAh+psQZKd+A0cF3CIq58wGhmB6Xfeev7xALeJpkXEcZUwzrMTv9cR6pEzeVjDVszfDlqLzriZ7tlmwBrrbjCa6lMDJkwO3pt4s7lyequf9fUvyAA+SVTLpqTw637P4hEIK1b99/W9bdUBeg5XMih9a7/s3GC20Sn6541i1quQ0UDcL8AOYJTivU4K7sJKywdwbLcE+DxbCV4L/KyjtfBXBISfBU9VMRUEihH5Ij35jExVuFKt2IENP2Draqc73NC9kreAOr5iigm+S02BjrLMcRzUnmAwdPVOm15hyOJWpPzlcJWO0Sf4NPSoAhTXa9HzFc8cnT+zJmVjq1J1JqVSeGmMFzaSW+LqVWUPMj21XxXYSglxnAijFGemXg3jZsYqbaAF9yxqtx9sn1pvFJlxCCqnUOcRAmjlygAQY+HeO1z6wuRY/qBcOA0Z91Uus8JBRRppvc/o7QieclcGm5jYfv0AclHppi5Q9dnagjP1pm/ATVQh7j68k6AUdMfr1F5H6AhKyN/oM3mDKO11NqJTFWSxUehsnnD/uYu/9KJ+zVWIxHNiyILHgfME4= 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)(376014)(23010399003)(7416014)(1800799024)(366016)(4143699003)(3023799007)(10067099003)(56012099006)(5023799004)(11063799006)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dlM0NE42WXErMnJzMWs2Ri9weTJ0R201MzN3Y2F4UDNHbHpFSlMyM1lGUXAr?= =?utf-8?B?S0RndHBCK2JjNTlUQWpuN3NlU2RFS0tZaTdxR3psL0UzU3c4WS9zeElUd2lW?= =?utf-8?B?ellmY2tadXBsRm1DaWhEdGVNVm9rRU1pdERGbGZCMko3MzV5THRvT1FDa0xR?= =?utf-8?B?T0Q5WjNNMHlzelhncThXVjNUNE9EZnJSZE9FVDBXV2V3UVdCS2Z3WHJFYmk1?= =?utf-8?B?RjRSSVlJOFNVc1hQc1dTTWpUb0JUL2lreWF1SG5OSjVWTHlLT2gvZnEvWWlT?= =?utf-8?B?NHo0NHFvZENKQi9FZDB1MVJaSmIxR2o5UEl3THdqYitYQXkyZnprdEU5ME5j?= =?utf-8?B?SWNxLzAyRGNud2c4ZWlHKzhUQThrMUhXRmovVTlsQ3RCdlJWZDR4NmFpMElz?= =?utf-8?B?bHFSaHRkSTZlbXNPWWt0eTE5bVMwc0QxTzhuZm03dHVvTDY0QkhUSWpZM09m?= =?utf-8?B?Z1Byc2tWeWV3aVZ6cEZRengvczJIczh2VzdaQVJkaFQxazZ5eFdWN1ZCSktM?= =?utf-8?B?VjRNSHhrK2NCdmFjRTMwbXB5cWpaOUtDS0hSbnpnN2dWRkkxU2g5akYxa29y?= =?utf-8?B?bHV3ejd3Z3dOUGdQeHFCSnVHNXdhNFFLWVQreWtJM0k1SmpaZ2NyYUxTY085?= =?utf-8?B?dUFZMFpYVGR5NXRYdGZrQVZlWVZSdDlBTlpTZHRpV1U3MFE5MVNPQTV6V1ZB?= =?utf-8?B?blNlUG82ODd1L1dIMWw1UlFTVFJvZjlZbU5IU214VkdZck9Xd1VyWVBJV0FX?= =?utf-8?B?WWgzZTMydFZjUWxwVXhIVzVmY0hka2ZIYlNoR0pTV1d5eWJ4aFFpeXpRWXB0?= =?utf-8?B?WjQvdk4xLzRMUUlHMHh4STBmZ214UGNIeTdxeGZaVy9aS0Y0SUo1VUNjUWxH?= =?utf-8?B?cERGNG4weEZ1Z1ZuRTBIZDdOSml0Ylp0OTBRUHIrZkJ4ajJYMldLMnYzUGdR?= =?utf-8?B?V040dW1ON0VpM3NFSi9JeDkwYUZMWU1hdzdaNG9Ed1Y2VWdWZVF5c1EvY2hY?= =?utf-8?B?VUVvcFkzaWp5Sm1MNFVocytjaHZEaEFhZUdLTlNiRE1Ud0RwanZBcjM0VWh3?= =?utf-8?B?V3kwdW5sOFNuOXlna1RaQ1ZBMFdlVlYwUXJFaDdwRXNhZ2szMzU5SzJiS05w?= =?utf-8?B?K3hQVWRqRDdJZkRmZk9kWWtCdEM0bjZqMWdLSUU4TXk3UTdodURSQWQ0a1Rv?= =?utf-8?B?QUJKekdDcUtjRkM4eVpwbkpwL3hlVE5VV3V4WTJmOHU2VmlZMjRvSU5ZTFYx?= =?utf-8?B?bzlqSEhOWCtMZzZ6VnQ4ZmI0cElaZGtMK0poNnZFcC9GR0lCaGUrRmVkbUpr?= =?utf-8?B?QVExR1cxV0FpT3p3cXZPbE1nT3hEWEJRK1VzRVZJVVU2UndFcUVGYXFzZWc2?= =?utf-8?B?OVRRU3M3Rjg0bThHdEhYS3hnNzkvVHRrdUpvVktPOUVwbW14VW9lOUdYQm5h?= =?utf-8?B?d0NLQ1ZzOW53Mm5waEIyYXZ0dzRWWGFaaXZRSWtEeUtmTjFlbzdvSWlNYy9z?= =?utf-8?B?WnpVWm9YTGwzbm1DOHJTK2dpeGlHNnhEL1lMakx0N2JwaWZudzM1eEZDbGVj?= =?utf-8?B?ckdid1A2bkVDNStnZTVia1daQ1E2cG42R3BjckZ4Nm12ZVZrV2hQNWgxSGZq?= =?utf-8?B?ZGRRc3JTeHVqY2o0Y0FtcmV5OHUwVjhVNnM3eUI5R09va1R0ck8rcFBNVyth?= =?utf-8?B?eks4ZWtLSGt6SlYwWExNaTZsck5SMWhLd0g5ekl2R25NNkRIQk84VGY4V3VJ?= =?utf-8?B?ZWRFcFZyNExyV2Z3eE5oN3JaVEFGNWtkeGhiY3lIT210anRrQlVXVCtFM2dy?= =?utf-8?B?SkY2UkJ1MG5RVk9wdUowczdsdHBkSGRNRC9BdE1wKzBWRDIxMDhIOFdhY0JJ?= =?utf-8?B?SGUwN0hzQXZTVHI3L0JpNmwwVkxpZ0l4QXU4NU50MW5QYUpsSlpncWV4anlz?= =?utf-8?B?UGhnT0FTRG9OOFpWUk1KRE4yYlQ2WjBDdlhzYWgvS2x3M092VkNrcjJWdzNT?= =?utf-8?B?bGNiZzl2RUZqS3Qzdk9qK2Q4TjJ4cVQ1cHNHRFlBOEQ4NXFWb096UmRDd3N1?= =?utf-8?B?SEdScStveUlCZUE5bUYwT2plZlQ2amZEUUI1eWoyTGtMaGZ6dVRvcktwSTYw?= =?utf-8?B?WjRJYktlMG1VTzV5VGVYQS9GN2dWVkJVZzdOVmw4T1RGTlJ5VHAyYUdQWWJS?= =?utf-8?B?blU3NUJRZVZ4OTZhekxNNWpha3I5QW9QNERBMjdPMlNGUnlsTTlrak9LQThK?= =?utf-8?B?QktDQytMVVNOaVl1d0Y0Mi84S3pjZ1RBc0JFaWx5emZManppQllPTi9kNGdk?= =?utf-8?B?UjdFUkRoVXk3Z1NzTGZ0anBFc0k5QUNxZHF6eVRUTDRtRzh3YlNVYlgvWFJs?= =?utf-8?Q?BuKfxh04kA7MpZZo=3D?= X-Exchange-RoutingPolicyChecked: aqCQyyQfejbKm9Z+Jw8/1d2K3tTt5FK37tYu4eO1xZ1pLeBO1WeM5MTnuUt67v6AEpnL9YT1rl/K7Qv4+AWbSHDdYn7KUWU5oZFll8a7Y8RuLgydEvkSoq9zZXQc3WmvpYeXIeRMWNdkdR7+MGFLvSOGlRuHKxB1P3J9N6KIBGCBmZ7+iiPoEsjlNT7OKqqjvjNQub+HMiiMAVzoWoSdpgKwiyq7Rrh3pxVS2XHZqC7Hz0qaYHb7I0OWjyc5g6s0dbQcXlkBfexRyPYTNsqI4PTHWzD+6kvemCNug4fKCjb9Xqp39fwm+iWlJzXJx9ejTg2EwlUmZiWqrpImFIoCQg== X-MS-Exchange-CrossTenant-Network-Message-Id: 15784a38-96c0-4aef-47bb-08def4d6b2ca X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2026 22:53:29.5030 (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: fgH/fDKoVdduRPk3/b0c7otRA35cJrkAfh7dxQYANw2nShdcibZ9edXWyFiDaDKMCPQl4C2CMu0qTEQg3IZujKBTD0S8zDVnlbViTT2vEQ0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8382 X-OriginatorOrg: intel.com Hi Everybody, On 8/6/26 2:24 AM, Ben Horgan wrote: > On 05/08/2026 07:06, Reinette Chatre wrote: >> 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 */ > > These info/ trees do express the difference between the two, GLBE and MPAM MSC at the memory. These > both result in the same schemata file though. > MB:=... > MB_NODE:... > > This gives a potential conflict if GLBE is paired with memory allocation controls at the memory. I > don't know if this is likely though. > >> >> 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? > > This is likely just a terminology issue. My thoughts are that, in a similar way to the L2 and L3 > both being cache resources but a different level of the hierarchy, you can think of memory bandwidth > at egress from L3 as a different resource from memory bandwidth at ingress to the memory > controllers. Sure, they are interdependent but on an MPAM system you could have MSC at both > locations. On a system with one L3 and one NUMA node and no other caches in between they are the > same resource as they are just opposite ends of the same link but that's not the case when you can > have cross NUMA traffic. > > So in your diagram above info/MB and info/MB_NODE are different "resources" and info/MB/MB_NODE is > node based scoping of the info/MB "resource". Do you have a good way of referring to these resource > concepts so that we can be more precise in our language? > This thread continues at https://lore.kernel.org/lkml/81f465d7-d12f-4414-9824-85d3cba5a36b@amd.com/ Reinette