From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 1D7583F9F30 for ; Fri, 29 May 2026 18:06:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.15 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780077977; cv=fail; b=fmbXBZUJ0AF/5c4S4HKylicxz92CiToYYg8VqJa7frdV9sK6OzhKVTWSgXBTLuf5PupnXb/0RaiAyYjoZxdDm8SXVjjt8J8dXsNAGNAxN4F6KE5it7//iejZQpGpq6O4HqYRGVmfH3+o2hyCDYiDeAoFqOqzbz7OL+rEN2x2un4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780077977; c=relaxed/simple; bh=pgIwIQG32KSGKAlZeEHnNFR/+NN+u2tlARqcOHvy8YA=; h=Message-ID:Date:From:Subject:To:CC:Content-Type:MIME-Version; b=e8KPSqpo6448hwFJtJ0vcKOtIUHilVdNhFVcZiO3qYSLB/wNU2vzEpyCdOsLGMv/TySwJn9/H35joi8K8NGRkqhbOKrS0vV0B+ge5QtVos5gtcZBfZSVw3fKyN616K2oKhylGa6OUwSwTXPv2dFBnxHkZOwcFI7skBGzwyGL6ek= 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=Bkr8lwA0; arc=fail smtp.client-ip=192.198.163.15 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="Bkr8lwA0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780077976; x=1811613976; h=message-id:date:from:subject:to:cc: content-transfer-encoding:mime-version; bh=pgIwIQG32KSGKAlZeEHnNFR/+NN+u2tlARqcOHvy8YA=; b=Bkr8lwA0fWK0TcRWxn4ihaLBWUGfdlCR2OzahlCdwRVlmfeeLbFJDc32 0vp7PADmRMRtF7GOn5TCx/pmQG4VjofMxbvAscKbXMY8i0+LB6FOXMdU7 1HZ1xj4C9l2/cckGWz4RVC0nTfEchXFiptrbDt3rAtLO+3UNqKQqzyCvc T/McvjVnuDhnykTK4sPFLahz03sBvDH2XBkxP5kIiih5CMtaD0/S7yC4x Ydvn9gSW4V++m2qj87trpoyuTtbl+ebM2j+NwFh2J6uDqttnkj+sIVRcT LAiFycUDt8MPiBRjNihf+apefTAJR/D60LNIK8cUmiAKZhPVJ90/zvLQ+ g==; X-CSE-ConnectionGUID: /BfuoRMNRcextc3pABEp1Q== X-CSE-MsgGUID: EXLWWH2LRVW3A/m+HdNaDA== X-IronPort-AV: E=McAfee;i="6800,10657,11801"; a="81050180" X-IronPort-AV: E=Sophos;i="6.24,175,1774335600"; d="scan'208";a="81050180" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 May 2026 11:06:15 -0700 X-CSE-ConnectionGUID: 1cUU1kwDQhy/1kjv43mIKg== X-CSE-MsgGUID: mNsDA+ycT/CT7sXhe6Dyaw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,175,1774335600"; d="scan'208";a="238730756" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 May 2026 11:06:15 -0700 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) by fmsmsx901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Fri, 29 May 2026 11:06:14 -0700 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) 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 via Frontend Transport; Fri, 29 May 2026 11:06:14 -0700 Received: from CO1PR03CU002.outbound.protection.outlook.com (52.101.46.12) by edgegateway.intel.com (192.55.55.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Fri, 29 May 2026 11:06:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vc8eAPYEFaKM7GEQwaz7BQCZ9N/pkmqXagr7l31UrE3MgqMk9BZNfT+NMlxL1je1tz21iDyD3qvNeMLJLDoXkgrWlidGXLe3Ew9LCyJ9MNgHfixWWRzqF6fnUsCO3fIQfJBrdf+EUjtw7hJf5DYJZbiSExiQEamgaV8DLo5IvCnsxuEeuLzKtMz4Oee+eSMZb84/IoK+fLNdA1JUYQKpfDmm+G/yT4PeG2/eBjhNy7Ra9D+Cx/J6RdDcVfQxsd72KaPTiPtaDtWKkLMJx5zLyZkEBP90pHcH4RXbpAx5PmlPPDM31b6bfVXUu4+Ky7C5YpEWqtY/ImF55NRBgo38kA== 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=Fw05fHO1Z4/ASVG0IHLWeo373MJ3VaWqkgCERjhMmWI=; b=QdmB7TjMLtB/ogw7zysCJnhCG/wywe81zTwWRPNZD8JSakzOaTxh0/n0kZoKUoxllcT6tkEIZKkpXt0wZKEVpRXRsKUarbu2ncqDOK1o9IUYuURhtghD/KcBd6pHgiH4gNRVNEhwWZjvH600x2jcW5PrUUHjUd7qgUb0QspFCpFbacSVk/uTW2vUnnwoK7idYxkGdm4ue3Q2XXPG/TTU9TjpTMr0KCnkf1k3azZyHo9TPq/mEUhA8FcGM6Kxk/8zqR6onuN+RGE4q9noLFa0AQMTaDaIR19O9G/Y2GNCAG/fT5aRhalhKeXWWWz784KmgypkX6N6qhCwM+RKOrGXOA== 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 DS0PR11MB7311.namprd11.prod.outlook.com (2603:10b6:8:11e::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.71.15; Fri, 29 May 2026 18:06:11 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%4]) with mapi id 15.21.0071.011; Fri, 29 May 2026 18:06:10 +0000 Message-ID: Date: Fri, 29 May 2026 11:06:07 -0700 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Reinette Chatre Subject: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Tony Luck , Ben Horgan , "James Morse" , Dave Martin , Babu Moger , Drew Fustini , Fenghua Yu , Chen Yu CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR04CA0074.namprd04.prod.outlook.com (2603:10b6:303:6b::19) 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_|DS0PR11MB7311:EE_ X-MS-Office365-Filtering-Correlation-Id: 6fdb9b3e-b7b6-4c34-e386-08debdacf6c9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|3023799007|11063799006|56012099006|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: jCGTf73hWGwDoMImRXnvRD1ppW28sLPtSLDQqU+RYJwnaxecqBHrzwMR7/pNH5w/rv4kIK8KyhUkd4CjDvLA3YqMl5HvXrcCLoV8J2oFOU2e0l/1yq50N4OM8D5JR/80yt78vrg6F99JGgzeS+IoWdasMU5FsbLhNuaJSPyOwfzGymRciHXvLM46eKaCX9DLTEIOoMvPnn22ELvmKqEfcMCQ9n6pnCLT1gWrMdm9/rq6WcOX9Gz6YYbPv6q2a+cLVTpmPsDu6u8tE9yScQlqi3AZx9tEpnZz0GjomEUZa52EENHKqx4SDfsQu7kFXUgRPUafKoN28NL6MRCraofCGt2z67h8cTOOOADH4x9M484F66rtRe0mGHHAX7esEncijlGj3qR07YNSnQ/nVh6aPz7FqguGYiO/W2W0FmsNpAoB5jAqCsBi+FYnH9POMM8OvrpR55r95GrpUhu2NxBQrlCGIK7zeVxfiKpXjiBkm4zyeAp4GMlzNtp005XiJkUWXgYsGVFR7pb1R9RzOFgP0ncNQXWZEUkIo+kRLnwv8QfFJdZMalyogTtSI8rxvDlwlfuV8BZLiMX8r8efsFDiuWD7w/zRmuK/xpdbY1ZP+TKRL2ew3orpS6b/7fjflWqwv9wdebkfft9U2avj2o4HoA== 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)(1800799024)(7416014)(376014)(366016)(3023799007)(11063799006)(56012099006)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L0tnLy9GNkNMdHc3a09FaW14c3FLbE4yc0JsWFczRUZNdnpKNHcySjJ1R1JB?= =?utf-8?B?eEVEZUxGV0FndStRYzFLQWcvRHdkR29qaWtaNHB0eUJhdW1DVW5ydXk0YWh2?= =?utf-8?B?aEpEZk96NWxpeXppQ1BUUFkxTGxLVEU4SkZTdTBsbHg5YkZIcDUzb01wb0Nq?= =?utf-8?B?ODZlaUVUZ3Z3SjFVUG9wT21QYXFRc1A2a2RwZTdVRzhORWZ2QXhQK3dUMENw?= =?utf-8?B?TEFQN1pnOVQvN2pJUjhNL1VhZ0FPWmVHMGxieEVkWTZpMmxrREhNL3V1MEhS?= =?utf-8?B?ZFNXdGFSL1RaeG1KRW5iMHhoTDNvc29JZ09OZjA5VW5kTkpMYUkyclFWK21I?= =?utf-8?B?TTZCWmx0K2lWaVZoY3NzMlloTll5R1dybjNmRHdJa1d4Vnc3THM2WnY4WEhw?= =?utf-8?B?U2c3dU4xbzg3V1pkc0t1S3JWb29vY01OZ1BYU2FoSlhybGF5aS9qU2xCZ2lQ?= =?utf-8?B?OHdCQS80b1JpTWt3YnY3TkNURGZzTmFxK2tBKzVoL0xVWGFoaTJXVFZuV29q?= =?utf-8?B?amJtdU02SDZRRUwreEt1c0wyd0oxU0h1Sjg5aTRpVWlBakd5N3BlVk1YelFK?= =?utf-8?B?VFAzWTlhc3M0c3NKWWg4UjJ5cWQ0V0t1YVdsWHFHTUpqK0xldmlWbHhjcDRy?= =?utf-8?B?ZFdpU1RYQUkyekFWRWpRcXQ5OU9HL0h1SzIrLzV4aHA5T2hqUWJSd05XWEhL?= =?utf-8?B?NEluUEtOa0VRaWE0RnJjWWJlRkNFQ3ZaQVZzMXkzZ0pLM2dGWWl3a1JKQjMx?= =?utf-8?B?dWxBRWtrT01qTktrKzk2TlluWFpsUDVTdGd0bDRCcUVsQTlGbzUyTS9yNWhS?= =?utf-8?B?RS9sOUNUNStwK0pOeGQ5SFR4R0RhdlNBb0d2Y3BTck1EY1RVaTliYTFROW0w?= =?utf-8?B?ZjB6clRaa1R3Skw4V0dSYmVSZ3htMGpxODRSS3ZjUi9HOXJBWXRNU0pMaC9h?= =?utf-8?B?OWJKMHY1L1lBcUxKd2dTNDkrd3JxU0t6ZllRYWZMeWFGa25pdnRYeVFTZ1J1?= =?utf-8?B?cGxsdDE0K25vMlFjdmdzQmc0MDIrSFBXMERIOHRrWHczTFB1QzJZWHBzb2JY?= =?utf-8?B?RlIxakp4OCsxVnExNjhvb2dVcVJoeURqV3IrOWl5amo0SHk5NjhWNTBtK2Fz?= =?utf-8?B?N0YwK09hczdCUXJ2b2E3OHpPMTlDLzcyRkNxdHVPajQwbkV6TWNjbm9kVE9j?= =?utf-8?B?WG51ZFpSVGZXb2Y0NG9UOVZvcExFSjM5NDNCNUFjOUVRQXpJRC9Qbk8xU1g5?= =?utf-8?B?cEpGRmdFWFdEMHNtcjhYZnlmdTdRc2pwVnJ5M0hhek12eE16QWljenltYVMy?= =?utf-8?B?SU1IYW9PbUY5QklOVjZnSjNpSjg0STEzOElLM0ZscVZnYUpZa08yeGtHVDZR?= =?utf-8?B?eW5rOG5EZ1k2V2tYNTByK2Y3bnU3dDdJRm54TkpmSm0zd08vQm1paDlhdmR1?= =?utf-8?B?Q2lRZGU5RFZmWDRKTHJoYXRob3d6L0dlYlhORmhGQktiOWN4SzJydndJNVBy?= =?utf-8?B?UnVCZFYzWDNNNWt3ek9ROHZBanJlRDlJRjRxRmEvbFBVQTN0VGZZRjUxNHJG?= =?utf-8?B?bWhTb00rcmRYTHhvSWFsVUNsdS94aFRLMGtpb09kWURDbFpXVHhpTXRhajFv?= =?utf-8?B?ckpidG5iMWc5bVlIRkFOaG1uQnFkKzVoWG1pdVpNbWZ3a2Y1bW5kdEMzdy9t?= =?utf-8?B?M0NSTEZkUE1XSWJlMUFYbmw4UHRLVFhmMlJldE5IaUdiSGxBU1dBU2tlMjgr?= =?utf-8?B?WjY4TkZHdnVac0FuNjkrdnlhV3hyV0pvbWg3Nk0rVFVzM2xEZlBNbS8xK0JW?= =?utf-8?B?Z2daVGlNWWxNbTNtNmRqSHVCYUxZOEFlN29FOEhVTFI5Mk5ZYjNOUXlldjVJ?= =?utf-8?B?ZjRYVzgzVWgwbC9qbUFLaEt1amRBVjJqMTdCdnZHU3BDUW1vQVlqTEJvWXg5?= =?utf-8?B?MVB2a2VjOTZSK1c0UGttQ3BzdWdZcjNYWjRjcjNOOWwrcDUwY2ZwTkdkcUhv?= =?utf-8?B?V1BQQjVCRXZzQ1A0cjBpVVJOVzJqaUpVb3BIbVhMUU9ib2FFR1pYYnl3clU1?= =?utf-8?B?MElpeTFpWEVXTEdDV2xiRWNXeisvQk1FMUNMMWFkVmE4MSt1QW5tc2NaZ2pQ?= =?utf-8?B?ckZLZWllaWZTc2JGMVJEL2ZPRFcrQnl4Vjl5QTRuVWVYV0I3em1vMVhOVXFo?= =?utf-8?B?OHNzN3FaNnIwcFpLd29KRkVhUFhWSkRPWm9OZG9OMGNQNi9FZ0VWU2FjZUNp?= =?utf-8?B?MFBHb1JYS2tXajNQZ3ZEdy80ckR0bndqSVRmeU50MnJqMkR5N0tEbEtPZ3ho?= =?utf-8?B?QzJxeG1kSCtFWVFlNjBmdWcyVGJKRENhcFd1L3VxS3VETkpQMm9ad0tlc1Bp?= =?utf-8?Q?eKNwyxsPUgG139nk=3D?= X-Exchange-RoutingPolicyChecked: nFeJhl89tXd1yW4/rYry5R725IJB1yXWMTIDo1KyrkWQYaCC4z4256r1ByttXQimUlcBw+Z8VzI2fWMeEcHk36r0ZZsCQ/To+5w5a6G+JoHO3tvFsYR+bE/7ah47pH9B+zfkb3SyEYmscbTzs0na2md6K0NitXRy0ntkCHiG378WwnOmutkKaF3CTwKs8HEubkZhBcRAkaOE7wEHs0O7WdbVUMFqBy8lkoiGYPKqx6RIUL69jYXYrBo0DHvNu1M97ZCZLoR3oDgjG43SMaRAeapaWQXfEaRqjaQoSRUsZqqxF+S/55Vssl6QX53L+sEcoAZZHZ34dTI+9lsJl5l6lQ== X-MS-Exchange-CrossTenant-Network-Message-Id: 6fdb9b3e-b7b6-4c34-e386-08debdacf6c9 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2026 18:06:10.7962 (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: Z9qJRpbE9uWqEWM3lOJblTvEVeOLLtmEuR77Fo8Ng7gH/K+NRe7NYOfTmLX7UOm0c7+fw9NpHGzdDf+IVL4344JCXDwNAJ7RscSEr+vUKSI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB7311 X-OriginatorOrg: intel.com Hi Everybody, It has been a while since we discussed the resctrl changes required to support hardware that has controls with fine granularity or hardware that has multiple controls per resource. For reference, the most recent email discussion can be found at [1] with a summary of discussions in last year's plumbers slides [2]. I created a PoC that I believe supports what folks have agreed to so far. I hope this can help us to restart the discussion with the goal that resctrl gains support for upcoming hardware that require these features. Request regarding this PoC ========================== Please consider this PoC as a "direction check" on the schema description and multiple control discussions held thus far. Could folks working on enabling new hardware requiring this capability please consider if this is something you can build on and how it should be improved to support these upcoming capabilities? Opens ===== While the PoC aims to support what folks agreed on some opens remain: - I attempted to make some MPAM supporting changes but these are all just compile tested. While MPAM should benefit from the new control properties I did not initialize them on MPAM and did not attempt refactor to separate out the architecture specific control properties (more on what this means later). I did attempt some MPAM refactoring that duplicates the MPAM domain to the control domain and monitoring domain lists in support of there being multiple controls each with its own list of control domains but it is definitely not good design. - No support for emulated controls (yet). The PoC is quite large already but I think it can be used as a base for emulated controls for which the software controller could be a potential first customer. In this PoC mounting with software controller will still display the original controller's properties. - One open that needs to be addressed as part of support for emulated controls is how best to display emulation relationship via resctrl hierarchy. - No support for "read-modify-write" usage of schemata file. This is where we discussed (without agreement) on possibly introducing the "#" prefix to schemata file entries. This PoC does not support this prefix and the current assumption/expectation is that when user space changes a configuration only the new control values are written to schemata file. I thus do not have a plan to support this so please share opinions in this regard if you have some. - Controls are independent for now. This means that, for example, if a resource supports a "MIN" and "MAX" control then this implementation would allow user to set the "maximum" control values to be less than the "minimum" control values. - PoC supports the "bitmap" control but does not (yet) expose properties of a bitmap control to the new info//resource_schemata directory. Accessing PoC ============= Please consider the PoC as a rough draft. It has only been compile tested for Arm and known to be incomplete in Arm support. To help with experimenting I only fully adapted the Intel MBA resource to demo two dummy additional MBA controls. All architectures should immediately benefit from the new schema descriptions and new info/MB/resource_schemata hierarchy. I considered the patches self too many for email. Instead, the PoC can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v1 The work is based on v7.1-rc2 that also includes the following series (two of which has since been queued) included: "selftests/resctrl: Fixes and improvements focused on Intel platforms" https://lore.kernel.org/lkml/cover.1775266384.git.reinette.chatre@intel.com/ "x86,fs/resctrl: Improve resctrl quality and consistency" https://lore.kernel.org/lkml/cover.1777419024.git.reinette.chatre@intel.com/ "x86,fs/resctrl: Pave the way for MPAM counter assignment" https://lore.kernel.org/lkml/20260506082855.3694761-1-ben.horgan@arm.com/ Primary resctrl fs data structure changes ========================================= Introduces a control represented by struct resctrl_ctrl that looks as below. To make the changes easier to follow I kept some of the original names to help communicate where familiar data structures land. What to notice about a control is that it has some common properties required from all controls (scope, type, etc.) and then depending on the type of control (RESCTRL_CTRL_BITMAP or RESCTRL_CTRL_SCALAR) there are type specific properties. /** * struct resctrl_ctrl - A resource control * @entry: List entry of rdt_resource::controls * @scope: Scope of the resource that this control allocates * @domains: RCU list of all control domains * @type: The control type that determines the properties of the control, * format string for displaying control values to user space, and * parser of control values provided by user space. * @name: Name of the control. Appended to final resource name * (rdt_resource_final::name) to create final schema entry. * Specifically, "rdt_resource_final::name"_"resctrl_ctrl::name". * For example, with resource name "MB" and control name "MAX" the * schema entry will be "MB_MAX". * @cache: Cache allocation control properties. * @membw: Bandwidth control properties. */ struct resctrl_ctrl { struct list_head entry; enum resctrl_scope scope; struct list_head domains; enum resctrl_ctrl_type type; enum resctrl_ctrl_name name; union { struct resctrl_cache cache; struct resctrl_membw membw; }; }; Two members summarize how this new structure fits into the rest of resctrl: a) resctrl_ctrl::entry Since a resource can support multiple controls there is a new list in struct rdt_resource named "controls" that contains the list of all controls supported by the resource. b) resctrl_ctrl::domains Instead of the list of control domains belonging to a resource they now belong to the control self. By doing so resctrl can support resource controls at different scope for the same resource. This is intended to support some upcoming MPAM and RISC-V usages. Example architectural data structure changes ============================================ An architecture can use the new control by following a similar pattern to resource and domain use by architectures. Consider the following for x86 where a new architecture specific struct resctrl_hw_ctrl includes struct resctrl_ctrl and any architecture private data needed to support the control: /* * struct resctrl_hw_ctrl - Arch private properties of a resource control * @r_ctrl: Control properties exposed to resctrl file system * @msr_base: Base MSR address where control values should be programmed * @msr_update: Function pointer to update control values */ struct resctrl_hw_ctrl { struct resctrl_ctrl r_ctrl; unsigned int msr_base; void (*msr_update)(struct msr_param *m); }; Structure of patch series ========================= As a PoC the series is not perfectly structured but to help navigate this work on a high level the changes can be categorized as follows: Patch 1 to 11: With a vision of what a "control" is, remove unused/unnecessary members, make clear what is a *resource* property vs a *control* property, do some renaming to help with the PoC. Patch 12: Introduce struct resctrl_ctrl and re-arrange existing struct rdt_resource members to form part of new rdt_resource::ctrl Patch 13 to 44: A lot of wrangling to introduce struct resctrl_ctrl to all code that needs to work with a control and/or domain without assuming that the control is the one and only control embedded in the resource it belongs to. Essentially, a lot of changes passing the control around in addition to the resource/domain. Patch 45: Switch the single struct resctrl_ctrl member of struct rdt_resource to be a list of struct resctrl_ctrl. Patch 47 to 49: Introduce new info//resource_schemata hierarchy to first only consist of properties already known to resctrl fs. Patch 50 to 52: Introduce the new control properties per [1], initialize them for x86, and expose them via info//resource_schemata Patch 53: Let the new struct resctrl_hw_ctrl contain architecture's control properties. Patch 54: Teach resctrl fs about "MIN" and "MAX" controls. Patch 55: Sample of "MIN" and "MAX" memory bandwidth controls for x86. Example interactions ==================== This series can be used on an x86 system where it will show two new dummy controls where it is possible to interact with the new controls. For example: # cat schemata MB_MAX:0=100;1=100 MB_MIN:0=100;1=100 MB:0=100;1=100 L3:0=fff;1=fff # echo 'MB_MIN:0=50' > schemata # cat schemata MB_MAX:0=100;1=100 MB_MIN:0=50;1=100 MB:0=100;1=100 L3:0=fff;1=fff Writing to the dummy control will call a dummy callback that just prints to the kernel log: "resctrl: Updata temporary MIN control on domain 0 with user value 50" Example output of info/MB/: /sys/fs/resctrl/info/MB/thread_throttle_mode:max /sys/fs/resctrl/info/MB/num_closids:15 /sys/fs/resctrl/info/MB/delay_linear:1 /sys/fs/resctrl/info/MB/min_bandwidth:10 /sys/fs/resctrl/info/MB/resource_schemata/MB/resolution:100 /sys/fs/resctrl/info/MB/resource_schemata/MB/tolerance:5 /sys/fs/resctrl/info/MB/resource_schemata/MB/type:scalar /sys/fs/resctrl/info/MB/resource_schemata/MB/min:10 /sys/fs/resctrl/info/MB/resource_schemata/MB/scale:1 /sys/fs/resctrl/info/MB/resource_schemata/MB/scope:L3 /sys/fs/resctrl/info/MB/resource_schemata/MB/unit:all /sys/fs/resctrl/info/MB/resource_schemata/MB/max:100 /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/resolution:100 /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/tolerance:5 /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/type:scalar /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/min:10 /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/scale:1 /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/scope:L3 /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/unit:all /sys/fs/resctrl/info/MB/resource_schemata/MB_MIN/max:100 /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/resolution:100 /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/tolerance:5 /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/type:scalar /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/min:10 /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/scale:1 /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/scope:L3 /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/unit:all /sys/fs/resctrl/info/MB/resource_schemata/MB_MAX/max:100 /sys/fs/resctrl/info/MB/bandwidth_gran:10 Any feedback is appreciated. Reinette [1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/ [2] https://lpc.events/event/19/contributions/2093/attachments/1958/4172/resctrl%20Microconference%20LPC%202025%20Tokyo.pdf