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 C71C93655DF for ; Tue, 2 Jun 2026 22:56:29 +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=1780440991; cv=fail; b=G7Hqf+Cqee7tu6ZsRssa7lKrgdFdDc148A5OiwCy9op/q7TrlCJ+AAhY7/3V4dlxPSRuUheB0qIsmS3bxMdzi7bTS868zSOFDNAadqSvmnMA2Hh7qYqRNx94L4rPLd0NIEkHBn3ryctbXG79lro++LL71yK284IlMXuzJpWNSs4= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780440991; c=relaxed/simple; bh=GxanBBcuocMI2MBpcZkoXrxdtKici4ekZtPiviG0jiU=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=kbkRKliwWL1eMNwDrtHzDpM1erLAWD6M1q6To/rfnegyHEGala8pGbhewwnOfc1zlQV+HAe4wuwkz4ylo1Z/jgUTLQtkQsr/LsfszSeEm9WqvOaVZEE0Ql+WSvx5eXSwZ5tnYOJ2EcTaoXZcScrAb9hjHg5lT5VsD2fiwMlXGlA= 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=lSob2g5r; 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="lSob2g5r" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780440990; x=1811976990; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=GxanBBcuocMI2MBpcZkoXrxdtKici4ekZtPiviG0jiU=; b=lSob2g5r6VK6bwl1yAmi9qvAwAiERfFVa8tH9fkgdGofumSvK5u+2kZQ 635qJAHC9lm7auMHafqKl9ZVQ2usB70Xj2O14KsUOLE8JDmXMnvo5kY0I PaSW/avhI1BVT1uf0JLf5yJff35M75EfiXdIidIUamoLz3O930GTYSIcM wN5VUL/fGgPABHHezYGQluXlnvE5i6ZGleRyv/M70j3dYo15wHC6SwXbw Tm9ISmp3SOFKZ143ZuEQZHJ/l7hVWtTcFsTDK8s2MuqXveFvSFnYqTxOH dxEDm5+Yo6mzRTAoGsyFs9pSCEGS10BQffnNyN50nENxat6RCB6hGfYv+ g==; X-CSE-ConnectionGUID: J8yHPQ2wRGuKBe4Xgo9eCQ== X-CSE-MsgGUID: FWs78L/DQICcTdOzPxyZkg== X-IronPort-AV: E=McAfee;i="6800,10657,11805"; a="81236072" X-IronPort-AV: E=Sophos;i="6.24,184,1774335600"; d="scan'208";a="81236072" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2026 15:56:27 -0700 X-CSE-ConnectionGUID: rjykZf1PSYG0ecdS8RtNlA== X-CSE-MsgGUID: xtWkpKpMSHCaIEp2DWlvnQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,184,1774335600"; d="scan'208";a="243187876" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa010.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2026 15:56:26 -0700 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) 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; Tue, 2 Jun 2026 15:56:25 -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.37 via Frontend Transport; Tue, 2 Jun 2026 15:56:25 -0700 Received: from SN4PR2101CU001.outbound.protection.outlook.com (40.93.195.70) 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.37; Tue, 2 Jun 2026 15:56:25 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=h6Uor9NcIkNSMORi/kG5qnvFByhz7PjWfcFW1NPjPS7AQ+A2oSR5UI9sf6P1bWur635WEs6TNoq5ZbSe68875ZO7U52AygCjUPsO0/wfbd9UGF4LGc8ne543ANxfyFweTEnlVivvN1TVroItZeiXzeAPOHEO/flLuFkb5PmdntXEt5HHIkqjZrZS5D6hg3aZNxiqjgFqoB9bXrs+2dxKeJg7l5vzI7NL+KbWpwsJSH13JiMjZ+dyIJttUwG61oVLxWQUkfx55VTUdXvEhDFmYIvekKcduwz7KN2qozQkjJEhPJmhzOOa51snTX+hhW80qPeNLwzcjvs7zfIXnJvkVA== 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=b7MjihgcmOStN90mwvy/np9gGwyMaRgyEt3uNcckScc=; b=tFvhR8gdjIodzsGt0rc9iQNmnI5Adsqcm4SeF6XrHt/0DnSNQ99RNpKt3rAYtwPrmjvGDkIb9gW297wN2jqzVguBgpYtIBgPoxhrUYjtU09JEyZVl85MKmEMgtSaTSlWKjg7NB5ik50jcmtvJGL/+JidXcicGkedsXrxtsJb2sIcoDUKvtL6w7p+L4Kh9SiRwYzGcYFXTamRXRn2r3H7kMoc0Dx3ZOht9PwUhCFVRszUCzsR0M877/VvZ0zrF06h9lqBSbPlWyfzvBQKn2itrAIkUneD82JnF5s7qy13H8oCwQZzOEgunWhrVXalPeKtSWRepmZIWriud3t2PSz8Gg== 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 SA2PR11MB4922.namprd11.prod.outlook.com (2603:10b6:806:111::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.7; Tue, 2 Jun 2026 22:56:22 +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.0092.006; Tue, 2 Jun 2026 22:56:22 +0000 Message-ID: <533f6b30-6d6d-4962-a7f5-b7b83d888f6b@intel.com> Date: Tue, 2 Jun 2026 15:56:19 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Babu Moger , Tony Luck , "Ben Horgan" , James Morse , Dave Martin , Drew Fustini , Fenghua Yu , Chen Yu CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <188147f4-db82-4aa6-adb0-d1a26565cfdd@amd.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: <188147f4-db82-4aa6-adb0-d1a26565cfdd@amd.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0307.namprd03.prod.outlook.com (2603:10b6:303:dd::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_|SA2PR11MB4922:EE_ X-MS-Office365-Filtering-Correlation-Id: d602e0f6-1e24-4c57-72b4-08dec0fa2a4d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|366016|7416014|56012099006|4143699003|3023799007|5023799004|11063799006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: +2W1lGXVvUkCQGjGElvQJxaEfsPZ7fIobQGZ+I37/0a3rlkAbLdx5fCwBTMVRbzLTDS4+ZXezoey2FLE5lyz6nnC43Cdu7MMOLziYRHkOksv94DlxyAYtdBTjZrl4BSXWXLmv8wWIItcjaaEGW0nRDZNZbSkhumPSp51TT/r3wjQHhZXdAs5JPKHnbXbn4LY2tvYtpVMQu73yTZcs71EowEvyKPLD9IODJwaLvYAKzuoopgezGQaeBVwirJp0gPU9HaFX6uZn7dNKBoZXSQIB6hwrOgUAa9NYRufwNHg25EAz0sa/vlYdcJCino3z4J0KDhJU4Q7Vyf0xOGX3yvAZve8gu+Xt+oKpqqFD6Z42pdLS6LufMY2MAcrRnykVjCxibbMJEjqXIlMnfUnOzkDRXSWcgkM4GrxnjlVa/fgqLPOZPi8brC17SwWbC71BgAJts/qsuZFKwDxLc2UmisVu0mG1xmdgRludmZLtmYaWvkCY4TfPths40hutzpVD2R+jeudPX1TVmuUE0ZAoabw5Ui7wRPSCyJNdzKMf3GkxbIqJWODvXKFeBYjyjImAjMmvwp/kBwDKkqSeRl0gHBOOuk6uSfsnLeZ+x+/o6j2AVdQJV/CCF0avxqoR9uuypv8xK9DiqLyE2fkYN4JMyEJ1Q== 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)(376014)(366016)(7416014)(56012099006)(4143699003)(3023799007)(5023799004)(11063799006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RnVVR1lJOUpFcGVIVkQwajh4enZmVWxzZUQ0VnBFMWM5VGNBa2Y2OWRvQ2ti?= =?utf-8?B?WnlMRDZmTy9WZjQ4bXBSa1d4QmIvak1pMVMwbXNKWW5BTTY4cmtmMlc0SjJK?= =?utf-8?B?SU8xS3RjK1hkMmV5ckVidnVjaVZ6VEFSUko2a1NVdndvRUdnVkJDT3Vaek1U?= =?utf-8?B?ODcvTVpYK1ArVGtMOSsyS3BTSDJiYW9lTGgrYmdMWnh2MW5RbDNhM09xUVNm?= =?utf-8?B?UWw1Q3F2UHB2d0dYbmxPL290bk5INnNZR3kvWmd0K3g2bGkrUlhhWjZ2cUtr?= =?utf-8?B?VnBZWlJya0Y0TkllU1NlU1RVOFdrSjB3dmozaUt1Q01YRVVJTWtiRVZUYkNp?= =?utf-8?B?V1VodEMySTFDWk03SGx1bWYyNitYTkhzVUpVN3luL1d2RmlPVEtRbWpWcXBH?= =?utf-8?B?NUJZWjY0cjJ3MjgzdmxJK1VHdjlBeWZVTW1VK2E5cWplNElNVFV2YS94ZFVG?= =?utf-8?B?bXEyeTc0VEZrOHFrN2V3a1B2OTdzMG1MYTZaS0IwL0hWWTF3N1BwTXdxaXBv?= =?utf-8?B?UnlyV3YxZ1UvZ05TZDRRTGxFRTNzRkY4MmR6eFQzWURFK24xWGZvUkFEZEg0?= =?utf-8?B?b2grUlhwYW56OGYvWDVOUmhoTUR4aDBrL0ZjaUxFcnJELy9MMU92Lzh6cC9w?= =?utf-8?B?WVArRjJsRm8vYTErNXMxb09UU1VEZGhWTnUyQ3l5d3U4MHpRdkNwcXpLem5X?= =?utf-8?B?Q20xcEVoTlVmMnpXVUxYWGQ5eVFHTG80RFpxQXg5b0xUbmZGSWNBOEJmODE3?= =?utf-8?B?cnJJZkc4ZzROOHdlZnNteXFMQkVjQnlWTjJYWDVvRnVkT3gxTGxtRnVEQXpB?= =?utf-8?B?NnQwR2VrR3lUYkE4TWFsMmpxZnlobVU2SXNSVDhDNG9YUTM2eDFZbFVRWkpv?= =?utf-8?B?dmJPREtuVU5ZUEUxZ0QxSlpoUTMyRS9mVkhBQkZCeDlHaWVBZ21sakUwdlBn?= =?utf-8?B?YzYvSi9YajhqMk82MVZTOWdzeTZuamROZzYzbnlFL1RLenRoc2pnOHFDU3Nu?= =?utf-8?B?QldMQ2ZwV2w5eTNTWTYrWDZPYnZ3Z3E1bVQ2N3VacGJLQ1VlWnRPZmNFVDlW?= =?utf-8?B?aEJQTW9TZHFNT1M3YlljZU00N3R6NGJ1eUlkUk1Mb2g3N2pQV04vemFWMVlS?= =?utf-8?B?LzJZVzhtNXVvSFVCTVhHVnFOaldOeWVoc1A4dEVleVB1dVhKMUVoNEZRc1lU?= =?utf-8?B?VXNFcno1Y3FWd3dnL1lWRkdLSUtJNkV1N3E4bms5K1VQb2F6emFxVmhWdjho?= =?utf-8?B?RTArU0hnaWVjNVRQdUNGOWxpam45QitzQ0k0Y3dQcTRUdWVxVkF0L3NPOWdV?= =?utf-8?B?MVYxMlhIdmhleE9sYU1NNTl4cWFjdGd4LzNJNHhKb01ZLytBYjBBWkY3MUE4?= =?utf-8?B?V2FCMGZ4RmV3dFJmWGptRGhNUS9FWmQvU3FlNjFFaXhYUVNmN1JxVmI4VDhj?= =?utf-8?B?MTFaaTFSSWpZN0tnc2FwU2luamVkaGlaUEVrbzE5QjNtZlFneHNFTUdGb2Fp?= =?utf-8?B?YXBDM1doQ2FFRWRIVURiUTRhajNpQUJ6ZFZ4WGJyaXVDbkw5bnRNQ0JtYkxN?= =?utf-8?B?VkFIeGhKZ2E5UGV5MWtSbUZlRUxlM2dHdU9IOTRFT2pQSVdpZDMrZ0RaQzdS?= =?utf-8?B?MjJTRHlzb2hVWUZNMGgyVkZQUDFKQUN0TkJFdHh4QjFENk8ycmVBTnlrT3BX?= =?utf-8?B?TktpNXlrRFZ4Tmhod3plbXo2aWo2bmhaVnIzQS9uV2Q3aS8rZXYzM2lHeUpG?= =?utf-8?B?bUZnNmVPbjdTK0hVZ05IVUdUa0wyeWxSTExaRDRTeENSektRa1hHOEFEQ0xI?= =?utf-8?B?MU56MEplaWZHeitRQmp5SDNucS9qYjdvbCs4WDUxUjQ4cnFKMTBUbUd3bklo?= =?utf-8?B?bzVGQ2RKa3hUci9FcFZwdm9UU2lZeE9IL0FJd2FidzhDUXc1c0VsYk9DNzhK?= =?utf-8?B?VkNFZXlKVFZHbWJ6U0tFaENWY1BnRlEyalRwU2VLSXZmL3JEbmN3YUVFMUlu?= =?utf-8?B?UTVqTy93ZHloWlhhQytHMWRLVEI1SmRxMWZyUDNCZUZmNThrcE5ZdGI1eVVI?= =?utf-8?B?anRsdG5kdXI4SXk2dW5velJTVHVsZitYRW9kdTE4T1lkUGpQN3hWRlEyU0hX?= =?utf-8?B?anN5V0dIbmJWVHZueGF5Zll5VmRIb005UUxzWXg2ZDFNWC9ZY20vWGwyQUtI?= =?utf-8?B?MWk5ZXNQbXVNSHNhNE1TK0c1REZKeHdXcTFBa1J5MlNINkhCeEhCdG0vdktx?= =?utf-8?B?WXRLSUdvUGV5KzdxdVQyRXN5cWZpdU5aNEhXbkVkSW5qWW15dmw4QWxSSmx1?= =?utf-8?B?NCtMS2JGM3Nab2p6ejJDMVJzZ1VuQloxNjVyMVJlMVBVMUgvYXA4UlNzaDZZ?= =?utf-8?Q?qXyoQU11ib2mZQFY=3D?= X-Exchange-RoutingPolicyChecked: MQZ13ZMcWtbCcGXQdPEGgNi0akqi/llc15XFZKzW1o7uB3GfbDPMfat+jQKjTCKrsqrbuJKinJTruG4s9vjGz07dE1niW6xkBaXonEJmV3Tn2pGfpy/2Ai3gBjpVP5cplXs+R7bdqjeGGqFaQNZKeylAQ3g9i70aTSV9JQqbTpZsjIgVVrwkMpUhSg0jO8vUvQPcRirK33OLqQACPZFGX5e8ly7aSKuWldKwsGpCIqvjK8y1CBp+L0O4BHbXI+MH4vXOwjuatGfuTigne7SJDbRmBX/8DA5sxYZ2ROpLtfW87sazEHcb6oTwczmqxealtY2dgbyoKBWRZQJyyXsYBg== X-MS-Exchange-CrossTenant-Network-Message-Id: d602e0f6-1e24-4c57-72b4-08dec0fa2a4d X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2026 22:56:21.9127 (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: FHREI4h/KPuIOAubYITRrqPAiY2lBkyUuyISKMaGGfRaxc66OZ7MolsuXti3z9o4ZUAgjg7A0q+ntJzJLoOCm5uREJripSiejOzDr5sidJc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4922 X-OriginatorOrg: intel.com Hi Babu, On 6/2/26 1:23 PM, Babu Moger wrote: > Hi Reinette, > > For some reason, I couldn’t find your patch on lore.kernel.org: > https://lore.kernel.org/lkml/?q=Reinette+Chatre How about: https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/ > > I eventually located it here: > https://sashiko.dev/#/message/aab804b9-e8b5-40ad-a85b-af7033391243%40intel.com > > Thanks for sharing the patches. I’m still reviewing them. > > I was able to build and boot the kernel and can see the MIN and MAX controls. After moving your test code to __rdt_get_mem_config_amd(). Thank you very much for trying it out. > On 5/29/26 13:06, Reinette Chatre wrote: ... >> 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. >>      > > I like the idea of supporting multiple controls for each resource. > > With these patches, now we have one list containing all the controls. > > However, in case of RDT_RESOURCE_L3, we have two lists "mon_domains" and "controls". mon_domains list deals with monitoring and control deals with control parts(multiple). > > Have you thought about making the list("control") generic so that the control can be monitoring also. It will just one list containing multiple controls or monitor. The control list adds an additional layer of abstraction just for control management, independent from monitoring. The mon_domains list is unchanged while each control now has its own ctrl_domains list. Here is an attempt to visualize how a resource with two monitoring domains, and two controls, each with two control domains end up being managed: +-------------------------+ | struct rdt_resource | +-------------------------+ | ... | | controls (list_head) |---------+ | mon_domains (list_head) |---+ | | ... | | | +-------------------------+ | | | | +---------------------------+ | | | v v +-----------------------------+ +-------------------------+ | struct rdt_l3_mon_domain #1 | | struct resctrl_ctrl #A | +-----------------------------+ +-------------------------+ | rdt_domain_hdr |-+ | entry (list_head) | +----------------------------+ | ... | | | domains (list_head) |------>| struct rdt_ctrl_domain #A1 | +-----------------------------+ | | ... | +----------------------------+ | +-------------------------+ | rdt_domain_hdr |---+ +-----------------------------+ | | ... | | | (next) | (next) +----------------------------+ | v v | +-----------------------------+ +-------------------------+ +----------------------------+<--+ | struct rdt_l3_mon_domain #2 | | struct resctrl_ctrl #B | | struct rdt_ctrl_domain #A2 | +-----------------------------+ +-------------------------+ +----------------------------+ | rdt_domain_hdr | | entry (list_head) | | rdt_domain_hdr | | ... | | domains (list_head) |----n | ... | +-----------------------------+ | ... | | +----------------------------+ +-------------------------+ | | +----------------------------+ | v +----------------------------+ | struct rdt_ctrl_domain #B1 | +----------------------------+ | rdt_domain_hdr |---+ | ... | | +----------------------------+ | | +----------------------------+<--+ | struct rdt_ctrl_domain #B2 | +----------------------------+ | rdt_domain_hdr | | ... | +----------------------------+ resctrl used to manage single domains that are capable of both monitoring and control but this was split to support scenario where monitoring and control of a resource are done at different scope. See cd84f72b6a5c ("x86/resctrl: Prepare for different scope for control/monitor operations") This feature further expands the difference between monitoring and control since now there can be multiple instances of a control domain (one per control) associated with a resource while monitoring still just supports one monitoring domain per resource. I thus cannot see how this can be accomplished with a single list. Could you sketch out what you have in mind? ... >> >> Patch 54: >> Teach resctrl fs about "MIN" and "MAX" controls. >> >> Patch 55: >> Sample of "MIN" and "MAX" memory bandwidth controls for x86. > > My assumption is that the MIN and MAX controls here are just examples, correct? > > You only mentioned patch 55 as "NOT_FOR_INCLUSION". I assume patch 54 should also be marked as "NOT_FOR_INCLUSION"? While patch 55 is the first and only "user" of patch 54 I believe that patch 54 (or some variant of it) will stay since we already know that both MPAM and Intel need to support min and max controls. Reinette