From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 C575C345751 for ; Fri, 7 Aug 2026 22:53:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.8 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786143208; cv=fail; b=aVX9/ojSQxDt5eJGxfzSWbOaalYOqPhe0x2h/8xOQqPi4KNMBsOkDa8UizPxdhj1Kvz/e1Wv5Xx0aA2RFfNHskySVsKi93m9tuG9Uwx1q/PepqsH7lWPchBlAGzn5DVL5R6QodAIqPIla6fQ0V5z9Xa8uZfa4sqFxUnh9v6DYE0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786143208; c=relaxed/simple; bh=CU6BHlr4SytQXLGIJ8l2GTK4yY5Ebl4g2WI0tqY6Vq8=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=Q3qXrPek6U4rjNqGKXCYoXFjKMRn/npt+3LwY8CZ+4Yrca085mON6x1ClweYqL2qfo6cGn/tKm/6uPGnVB+1OFEnkbd40Im3eZsB4TplC0i95dBVlvBZVw042azHlkegiSfZpFUXsvl9aDu+FgHk6RX6hPaUy7EtKsdXJTpJDr4= 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=PN89XnT4; arc=fail smtp.client-ip=192.198.163.8 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="PN89XnT4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786143206; x=1817679206; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=CU6BHlr4SytQXLGIJ8l2GTK4yY5Ebl4g2WI0tqY6Vq8=; b=PN89XnT4TAWOJaQMdv0HdD2s1YG7g/Uo2xAPWIUzS0nalb386nT9cfcj h19i3PnFRAdxHrtCg+qekOmiGvhomjK4MbccbU6SXVI9+fskf7ZO7bWts 49JkpEGrqEUJ0C1zswV5iqmL/Yga3Kmwe+Qvs3O2BbQtleyS6Pwkj2zKk vNTSbts063OqzTNGpKmLnMqCoWwLZGKH9bmKHvI9kOGI25qOfRY8v1Y2Z tGnu7Wj/8vtQBaWz6lF1uphaVQmQxLe68k5B9G7qayGBr+bo8qLN1Lj60 NUFC4g5jzlLADLik9cZ7BzxozElKiLsK9PkCdPhxyzGzsOfXQZRYEba0H g==; X-CSE-ConnectionGUID: 5TvKcoyJSgavXmD31sof2g== X-CSE-MsgGUID: 1X652xLBRBGeOkQVuwhsag== X-IronPort-AV: E=McAfee;i="6800,10657,11868"; a="104291568" X-IronPort-AV: E=Sophos;i="6.25,210,1779174000"; d="scan'208";a="104291568" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2026 15:53:25 -0700 X-CSE-ConnectionGUID: PgfI5W8HQVORc0eRReSq+A== X-CSE-MsgGUID: Xw6nVXD7St2VgyL0Zr37kQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,210,1779174000"; d="scan'208";a="266762097" Received: from fmsmsx903.amr.corp.intel.com ([10.18.126.92]) by orviesa005.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Aug 2026 15:53:25 -0700 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) 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.45; Fri, 7 Aug 2026 15:53:24 -0700 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) 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.45 via Frontend Transport; Fri, 7 Aug 2026 15:53:24 -0700 Received: from CH1PR05CU001.outbound.protection.outlook.com (52.101.193.35) 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.45; Fri, 7 Aug 2026 15:53:23 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jFaZQkH/fKhIdZu7Ku/ejDIWeQHqPuoy97a6Mo3I7aZHQfhRBm2fUxFEUJItwVstycvMw5+WAuLiLRi2qJDlInMHfllIM462Nv4TK0xD5d2XGq5rO2SjkvTHJWQvzq7XL9UVfFozgmLjdnBnlrK0MVkcsE/6xKCIlTG9S2qx/8pCyBN7vX9D2xvQzB4Sn1bvZnGk1c3klU3dZhuYGrzdz6g77TREPMSx2gJAfWk+dsfD7YJ2ore2MHKxw4WXu97ZsNpSXeLqPeq/Knwzo+kxqyirJamVKEfPFr3bGXFmn2dqXJiaOq98kh3QB4XST2qlDHUFDemmugl+KfWy8qF1EA== 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=W5Nw70QYUCSKfPhrTP/9O43nzZR8Q7I3ZnAGIo5pajo=; b=PzhfycoQzZfpHZ7tEI3f2VCmdP6WP/J0I3Tw9WX1Fy9r/LBwASWWxWC4xmeR6Da7opiIZ1I5JtKKMeBVoxzpfJceTLoL2lVqKIWiyYfZUB4v2a15romOgKZbFpmJnMPPRaTo7TmSQTffm5R4aYpVImFRgOt1Cpoo/837xFkm05Qst1KjBjlznJnmFPHI0AoQCTrsYE4xHbvWeZT90IYkT0jt/0RBxzLXnc27kNaHibIxgebix7cMpwvsJXqmKkmdmy/M1WxPXIin9JY0Bd6EiQhMDn0tH4nbD+pLXUjyGfHEhR2oxO8HSGh66BEbAWqjwP3SSzLEQrFJV5z/8JoOnQ== 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:20 +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:20 +0000 Message-ID: Date: Fri, 7 Aug 2026 15:53:18 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept To: "Moger, Babu" , "Luck, Tony" CC: Ben Horgan , James Morse , "Dave Martin" , Babu Moger , Drew Fustini , Fenghua Yu , Chen Yu , Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <7a8b6cc8-d194-4af2-9fb9-2438d2dcae01@intel.com> <9d0239e6-318e-4a59-937d-a64b839e02e9@intel.com> <81f465d7-d12f-4414-9824-85d3cba5a36b@amd.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <81f465d7-d12f-4414-9824-85d3cba5a36b@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0193.namprd03.prod.outlook.com (2603:10b6:303:b8::18) 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: c6ce18c1-922d-4c58-fd7f-08def4d6ad58 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|11063799006|6133799003|18002099003|22082099003|13003099007; X-Microsoft-Antispam-Message-Info: WhSv/8aye8MyUqke+Q9/csd3+avFg0bN22sbDxIUBnTv/a/0QIXBaALjXXVRVOwIa8NT5CirxBBO6oQ8zfV7ncwiO00aGvMGSbV7OK35e00qQp4xhfJdTndWSm+jyt2CVkbiBXoUzsHfrDrS7evRWXG64+F/ykDjkASNG/TBbYp4op78UYVMcFobm8h3juXI1OlrR8tYgKLtf8jl8qlUk/twFNjIiGi3CnOt/ur490k54bpyz5iqKd0xV9NW2BHygrEF2xslYi6tvKthWYmfPrcRiUu3+GV7+/NfVhZ8KKR5cK5kjt0R4NCv+iCKQhKrwmneIRtWmHp90g5ONZlQXmo/i4Z27BEf9suB4fefZIvWO+4de+0lk17vZNtT7fL4LDkenvSaIcctJMvgFzxT4ndXxIVHE1avKMnqs3wWCiTlVoewx7BfkZFF0F8DIk98NUOIbUEic3wbXwXWZuqYcCrmmg0ms0tgp6uAe51RQMQcEjX5XjC1QhGny3on8ul2R8FjH423iKvXbsrjW0WkqEKtgRcYfro9rtiv9O/UP3dpqzFUjlAmf8B9O1Z/yAhAYh1Qnzz0wvjvYBRJXeOazmGwlK6gEGuW5cTyx07NFcoiCiClO1AgQBd/6hrCLspm9pVXUbSkVOQSlZjbe98RysWH+1Pvng+6lqhjjHo29SU= 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)(11063799006)(6133799003)(18002099003)(22082099003)(13003099007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MlMwMFpreFdTWlRxZUVLYm9zL2dsUFFDNmY0YjUxN3RuTGlYZmJqODhQblZM?= =?utf-8?B?QmlOTEJ3dkVua2RtSFE5VStSc3ZMYzY0cFVvNG94S25OVFFZS2F0bnRmYmZH?= =?utf-8?B?RzlDL3Q5bzJ0Mngrd3NFcXRYclEzclYzc29JYWthTkJybDVxb29wcjB5N1FX?= =?utf-8?B?WEhOeDhWcGNyZSt0ODdmWFBocFVwaU1LM3ZWZWtmQlVwblpFSjdTbndiSVlW?= =?utf-8?B?OGpBU3VRTUx5Ri9BYVVTaHhWTW1rZjlNMm9GMkNZOEg3V1NzNDV3cUNkOEZa?= =?utf-8?B?VTZLL1Zzc01MQXpYNTNVSlRJd0RGQmdyemdGa2x4ZFltMnhsdFVpa1Zpais5?= =?utf-8?B?Ty9BWHBGQUhsdUtLUUVBeDFpVG9Vb3RGb0g1c2IxUjVzWmNDOGlsaUFNUG4x?= =?utf-8?B?MHk3eExiWnNzYzB3YkIrSHlPT1dnbmRwZTB0U0xiYzExbWFIL2VydkhGVHI3?= =?utf-8?B?S284RE56WmR0ckJZREFPRkVPd1VQUWJlWEVoaWpZbU9ZQnFzSkNmUXJVZG5I?= =?utf-8?B?ZDVRY2lmbUR3dnJaaFB3UzVXRGZpTlIyVjd3ZHprSDdzT2JUWi8rZVg2U3BW?= =?utf-8?B?emtYZmxDaThZRTZEcUFERDNIVEpFbVl3aXJhSkJkd1J6MHNlUjdTT2xXUi85?= =?utf-8?B?Z3phZGtzTndBVUd2ZUV4eTdwMkdZRDZSVkpyZ0VXbHhheXZjTjdQalZkclFw?= =?utf-8?B?SWVpYlBETHJya1NjRkRGbW1ZYnhObFFKYjl2L3VhZ2h2MlRJVkwxckNiNVVK?= =?utf-8?B?c1oxQ25LVHdFcm9heHlFRi9pbEsydkdXcUpiaEdzRW8wWmNUVFJ1WjhBTDVa?= =?utf-8?B?alJxaW5vWGdsL3AwMHBqOVd4WGtBbWhXMEdVRnNLRE1TYWRwRDBoeFBmQ2hY?= =?utf-8?B?cTB4TFJvV2JXNnU1QWFCcHI1d01EVFhuVmdvKzl1VW5NeWNYTGhpc05qeXB2?= =?utf-8?B?S2pxSFhOY1l1TkUweHBta2lJRE9sRkhiQ3o0U3ZFWDQ4bHg4bFVCdUF3SHBu?= =?utf-8?B?aW8wemo0WS8yRDk5V1JxdFJERHpJbEFmNTJjSHRVUG5GbmVSUGZPMytoRzhC?= =?utf-8?B?V0ZPcEpvVWhHNTVmeVN4MG5FR0FqT20xd2tQekwzRVJUcjFVMlJoS3hQYkpo?= =?utf-8?B?ZnhubGRxMG9PT0c1bC94U21PazFIc0FHcjc2a1YxcE0yaDI0eWo3UEFBVDJJ?= =?utf-8?B?bCsrMlVsMUlFdGNwanhRSitLenVDc3hQRFdhNnRmODhtRFMweUxTd0QxcG9z?= =?utf-8?B?WVJvRDQ5ako5UDBIZXBMb2MycFpKMVhjQi9kUEdna25DR0lXSXBkd0FBWm1n?= =?utf-8?B?d0lJRllhTll3V0lrTWFqcjBGaCtiT2tSeHZHOHY1WnVOc1BZNW9VODBLcW9Y?= =?utf-8?B?VDBwL1h2MENoaEJEcnMrS21WOURFTDJicEh2MTdPaU9kNGlBVUo3MmlZQnNt?= =?utf-8?B?Zmh3aW56UGUyaEIrQVV2blRSNWZWcVJMUlpHYUhrbGVvTE5qU0RaU0plaTlq?= =?utf-8?B?R2p2d2RLZWl5Vm1IZ1lMQXppVkpzVm80cDJkRFU4eDR5VFZyZWl3d1ZiQ3Yw?= =?utf-8?B?SlJwQWxldUtYWXVzdm43YXBSdFhuaVE2YmxreG1nMlZzRndBdjRHVE50VjR5?= =?utf-8?B?dWwrYmZhVDIxOEU4VkNlN044SmIwVFhGZzZwTS9BT0dTRGlNaWx6L3cwMmFk?= =?utf-8?B?Y3dOb1FFUkJKNnB5c3hhRTdTd1R6dDI3YVF2OFNoVllwbEdIU0g4em85aFhP?= =?utf-8?B?UTNkcTFLZDB5WU15NHlaWGhaV1RXRktPdTRyWm9jbWRGd3p0czlxQ1dTbFU3?= =?utf-8?B?VGV2T0g3OXkwMU5yMVpueThTSk45OFRjK2VpdUdiNkhreHNVQk5CbWZBMmNu?= =?utf-8?B?ZkJ6NVhLTXRXaFZ5S0J2WDEyY1cxZ052SlhtY3lrbnBnVlkxZU8yd012T1c1?= =?utf-8?B?bXFBbDhJejVNOUo4KzVLcXc0R2JCaEJiRXdpTWlvQjFVdHR5c3VpdVlvQXpn?= =?utf-8?B?N2RwNWhlaVVDdTcrNjRnVkQwUmVqdnBnODRaazBmS2YraFpKajZQUmkyem9N?= =?utf-8?B?YlBnRlBjS0g3b1BBWkNSdUVoM1FUeDZIeE9leUtKNlZYZWNGVnVORVl4bVVL?= =?utf-8?B?STFPR1E2U2ZWYXdSQWNxd01PTEdkWW5VN2taZHJZOGJLSnExc2M4dGRGbW1l?= =?utf-8?B?L1IybFQrcE8zdWtnYTNTQThtMHBVaVl0NCtqWUhtd3Y1WDJVbUgvYXlMZ2R6?= =?utf-8?B?bis4YytzeGN2eW4vbnRGUU1ibHV5dFBHclR2TksyT2Y3dmtGbkJEaTdxSTAv?= =?utf-8?B?Y1VxS3I1dlYzYlhMQ0Jyak9lSGlxQmFFWlJJdDlMcVFlS2NBc3hQMUNKRzBp?= =?utf-8?Q?MOq4bD2qhzZG8TpI=3D?= X-Exchange-RoutingPolicyChecked: eBLimEN/mkl78LS1ulHy4z/y4bZBjCH8Z49kjS+0zNEcnMIsitA2FMjQoznk7fBdc0gzahRguFOh+16e6GBSwjxra5+PyQkcbhEf5NVtg/DZHtnbG2752sLgjCf059rosZmCpstQyycc1Y+Hx141vKCY2xROfcMOKPe9/bm7sIW9obIKzKNe3/TUallugTgiF0b7/gkbtQl/Ph9o8IHm9JDxf6K9+x/R/IXc7SS9h6txEaCISGjYTqO0Oi0iGuueiSrEF3lonkPr1Wnfy+y4PqzpZFID17+eBrsa4PLx0UcmI3yQc23cupnfsXnH92ymeI05wbroQN5JRtjdryLeFA== X-MS-Exchange-CrossTenant-Network-Message-Id: c6ce18c1-922d-4c58-fd7f-08def4d6ad58 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:20.3798 (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: GJFkA+58P4TtYZXQ6knnNlBRfYHlt8qhJ9I/oZHGbH2FGdtsoWomYUtXs3puqDPPfILz9wi3Xx/CzKB3nbYyu68wB9/PyKiUHxlEn36OfEw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB8382 X-OriginatorOrg: intel.com Hi Babu and Ben, On 8/7/26 11:33 AM, Moger, Babu wrote: > Hi Reinette/Ben, > > On 8/7/2026 10:35 AM, Reinette Chatre wrote: >> Hi Babu, >> >> On 8/7/26 7:14 AM, Moger, Babu wrote: >>> On 8/6/2026 12:11 PM, Reinette Chatre wrote: >>>> On 8/6/26 10:04 AM, Luck, Tony wrote: >>>>> On Wed, Aug 05, 2026 at 04:57:04PM -0700, Reinette Chatre wrote: >>>>>> On 8/5/26 9:59 AM, Ben Horgan wrote: >>>>>>> Just given a go at running this on a model with MPAM and I can mount resctrl with this >>>>>>> small patch to initialise the emulated_by lists so that list_empty() behaves. >>>>>>> >>>>>>> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c >>>>>>> index 21dcbf5764cc..638095649151 100644 >>>>>>> --- a/drivers/resctrl/mpam_resctrl.c >>>>>>> +++ b/drivers/resctrl/mpam_resctrl.c >>>>>>> @@ -1018,6 +1018,7 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res) >>>>>>>           case RDT_RESOURCE_L3: >>>>>>>                   mpam_ctrl->r_ctrl.type = RESCTRL_CTRL_BITMAP; >>>>>>>                   mpam_ctrl->r_ctrl.name = RESCTRL_CTRL_NAME_DEF; >>>>>>> +               INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by); >>>>>>>                   INIT_LIST_HEAD_RCU(&mpam_ctrl->r_ctrl.domains); >>>>>>>                   __set_bit(RESCTRL_BITMAP_FLAG_SPARSE, mpam_ctrl->r_ctrl.bitmap.flags); >>>>>>>                   mpam_ctrl->r_ctrl.bitmap.cbm_len = class->props.cpbm_wd; >>>>>>> @@ -1048,6 +1049,7 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res) >>>>>>>                   r->ctrl_scope = RESCTRL_L3_CACHE; >>>>>>>                   mpam_ctrl->r_ctrl.type = RESCTRL_CTRL_SCALAR; >>>>>>>                   mpam_ctrl->r_ctrl.name = RESCTRL_CTRL_NAME_DEF; >>>>>>> +               INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by); >>>>>>>                   INIT_LIST_HEAD_RCU(&mpam_ctrl->r_ctrl.domains); >>>>>>> >>>>>>>                   r->bw_throttle_mode = THREAD_THROTTLE_UNDEFINED; >>>>>> >>>>>> Thank you for this. Added this and it is now available in branch resctrl/controls_rfc_v2.1 >>>>> >>>>> Is same needed for x86? I don't see any initialization of the >>>>> "r_ctrl.emulated_by" lists in similar initialization functions. >>>> x86 "emulated_by" list initialization should be in both branches. >>>> >>>> Branch resctrl/controls_rfc_v2.1 combined all "emulated_by" list initialization >>>> (for x86 and MPAM) into commit: >>>> 3407e523c988 ("fs/resctrl: Introduce emulated controls and control mode") >>>> >>>> In the original resctrl/controls_rfc_v2 the x86 "emulated_by" list initialization can >>>> be found in commit fbed64f80515 ("x86/resctrl: SAMPLE: Emulated controls") >>>> >>> >>> Looking at the commit: >>> >>> commit 3407e523c988 ("fs/resctrl: Introduce emulated controls and control mode") >>> >>> Based on the patch description, emulated controls are intended to be >>> used only when there is a difference between the native and legacy >>> controls. If no such difference exists, both modes should operate >>> identically. >> >> The original AMD MBA enabling did not follow the original percentage based MBA >> control so resctrl essentially has *two* "legacy" MB controls today: one for AMD >> and one for Intel, MPAM, and RISC-V (planned afaik). That cannot be changed now. >> AMD would continue to expose the MB control that is not the percentage based "legacy" >> control but actually AMD's native control. In short, yes, on AMD's "MB" control >> the "legacy" and "native" control modes should operate identically. >> At least now users could use the files in info/MB/schemata/MB/* to learn the >> properties of the control. >>> For MBA(AMD) and GMBA, there does not appear to be any difference >>> between the two modes. Is that understanding correct? >> It is not clear to me how resctrl should support AMD's GLBE. Note I am intentionally >> not using GMBA since that already makes an assumption on how resctrl will support this. >> Do you perhaps have an answer for Ben's question in >> https://lore.kernel.org/lkml/1444b515-752e-4167-87f5-30ace189e05c@arm.com/ ? > > Yes. We are already at RFC v2. Let me respond here. Please see my response below. > >> >> GLBE claims to enable users to allocate memory bandwidth at node scope but the memory >> is managed at L3. This results in scenarios where, for example, a NUMA node can be >> online and used but resctrl cannot expose it for bandwidth allocation when all the CPUs >> at that NUMA node scope are offline. GLBE is thus not actually allocating memory bandwidth >> at the NUMA node. > > Yea. That is correct. > > There are a couple of key differences when compared to the pure NUMA scope. > > 1. In some cases, a NUMA node is treated as the entire system. > >   > https://lore.kernel.org/lkml/8f77f498b1c77fa8fd8f5d5687f03ae598068544.1776980182.git.babu.moger@amd.com/ > > 2. When a user updates the settings on a GLBE for a specific node, we need to update the MSRs within that node at the L3 scope: > > https://lore.kernel.org/lkml/a2a06bd290e68f902be9e7cc3ad35f0a2211b950.1776980182.git.babu.moger@amd.com/ > > > Considering these differences, I think we should probably treat GLBE > separate from MB_NODE scope. What do you think? I think so too, but to Ben's point we need to be clear on terminology here. There are two usages of "scope" to consider: 1) The scope of the *resource* being allocated. Here "scope" applies to the resource. For cache there is L2 and L3 that indicates the scope of the cache resource. There is also now two different scope to consider for memory bandwidth allocation, "L3 scope" for memory bandwidth at egress from L3 and "NUMA/node" scope for memory bandwidth at ingress to NUMA node. 2) The scope of the *control* used to allocate the resource. So far the scope of the resource has been assumed that to be the same as the scope of the control. That is, a resource at particular scope is allocated at that same scope. GLBE taught us this is not always the case - memory bandwidth at L3 scope can be allocated at NUMA(with some caveat as you point out) scope. We have gone back and forth on this. Currently upstream resctrl has control scope as a property of the resource with expectation that the resource and its controls have the same scope. As a change to this RFC v1 of this PoC had "scope" as a property of the control to support a control to have different scope as resource. After deciding to treat MB_NODE as a new resource to support the CPU-less nodes, RFC v2 changed this back to have scope a property of the resource. First, it looks to me as though the RFC v1 separating control scope from resource scope needs to return. Second, how to name these resources/controls needs to be decided. This is what prompted my question about future considerations to you because my original proposal in https://lore.kernel.org/lkml/f5b6cec4-03d8-4a11-884d-d4579dab6b22@intel.com/ was able to convey the resource and allocation scope via info hierarchy but it used the same name in the schemata file that Ben highlighted could be problematic. I believe there is agreement that the resource should include the resource scope in its name. This is currently done for L2 and L3, and planned to be done for MB_NODE (the "MB" resource does not have "L3" in its name, this cannot be changed now, but "MB" resource is implicitly "L3" scope). The "NODE" in MB_NODE is thus memory bandwidth allocation at NUMA node scope - "NODE" in MB_NODE is the *resource* scope. Considering this I do not think that GLBE should use MB_NODE as you also state above. Since it does not allocate memory bandwidth *resource* at node scope. We also discussed before (https://lore.kernel.org/lkml/c78169bc-e2d6-4583-96ec-09fa6dd6653a@intel.com/ ) of having the control's scope part of the control's name. We could have a rule of thumb to include both resource scope and control scope in the control name but only one instance is displayed if they are the same. For example, what do you think of something like below as an alternate proposal of what I mentioned in https://lore.kernel.org/lkml/f5b6cec4-03d8-4a11-884d-d4579dab6b22@intel.com/: GLBE (booted with NPS < 4): info/ └── MB/ /* memory bandwidth allocation implicitly/legacy at L3 scope, think of this as "MB_L3" */ └── schemata/ ├── MB/ /* control scope = L3 */ └── MB_L3NODE/ /* control scope = node ("L3" resource scope + "node" control scope) */ GLBE (booted with NPS = 4): info/ └── MB/ /* memory bandwidth allocation implicitly/legacy at L3 scope, think of this as "MB_L3" */ └── schemata/ ├── MB/ /* control scope = L3 */ └── MB_L3SYSTEM/ /* control scope = system ("L3" resource scope + "system" control scope*/ MPAM MSC: info/ ├── MB/ /* memory bandwidth allocation at L3 scope */ │   └── schemata/ │   └── MB/ /* control scope = L3 */ └── MB_NODE/ /* memory bandwidth allocation at node scope */ └── schemata/ └── MB_NODE/ /* control scope = node */ The GLBE controls make it clear that the *same* resource is allocated using two different controls that have different scope. This creates an implicit dependency between the two that is not quite captured but having two controls for the same resource would already give user space some insight that their control values need to be considered with care. I'd appreciate your, Ben's, and anybody else's thoughts on this. >> Should resctrl prepare for some future where an AMD system may support memory bandwidth >> allocation at the NUMA node while also supporting GLBE (memory bandwidth allocation at L3)? > > No, I don't believe that's the case. At least, I haven't come across any information suggesting that. Apologies, this was an unreasonable question from my side. We cannot predict the future. We try to prepare for it with what we know today but new features always seem to come with unique capabilities. Reinette