From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azon11011029.outbound.protection.outlook.com [52.101.57.29]) (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 935671F94F for ; Wed, 3 Jun 2026 14:40:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.57.29 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780497656; cv=fail; b=Q+nh1Hsey8q/iY6WFowDs3iZEOXjACgKDYOxoJ4l2JDtFATUX2qu9NwjXRbQHZWPJP1DngXwxIMrBGsAw9Y83cs9V7ij/Bci58UGj56o80UwR3LCmXppo8HJgBHhcMVqPhPT7Kut0k8do99Ou64bollKl//T9ZJ5LdmNtCqleOQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780497656; c=relaxed/simple; bh=IWC1LFyFfQtSWrnQS1IqEggNw+xu1hpJk4EN/+YZWaM=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=JzrHVJmy2/f91pAKgr/eyLg8FyJbcxaFifHijg1mFd4rfRCEQBlRjx6z/0hzWFHJgw4qnew2S9KNqZpHWQrzV0IfZxBw2aS0eaW2jg1B1HxSKNhRdVQwOkLJXSTmplPzf3DohWgsKdxqn3V3Qyz44y/moHYrPaQTxpK6HU2Jok4= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=KIIwCZxb; arc=fail smtp.client-ip=52.101.57.29 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="KIIwCZxb" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=RoxhObrpIRrFz0mu2bL8YXz63lasqFqNsL73kEbuvNuywZVtbV9BI7KQxa/zF6WimWp4sRVH3zqMYAKHQ3X3OwayPmgzG1ucdMC4rzeMwbKloMDHaWpsCf1/F7mxTRzok3RwnBrm8NfG4O+m6k3p16ryum7CJ2rMQxLTOJ6bhkDeaWbYKl4ni7EOYOfEF2/KmzZz2SqJhoCdJW1WUM4rHwX0dZZwJZ7BSCR7Zok8n2XIQc5iy+lHoJck60XGqs66mLiB50iIlPU352Yi4nIGAs5lC0AVINsCpkd7J+dL1U4RZWnHXLB1jPH+HjeUW31pCXpZB9fdjQtoESUWojGZLQ== 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=UhXDWnPkbAZNRikemxKSXUhTt6moN5yrqiyyPzoUVKc=; b=KNUTocrQbnNQBSKabV5nBoT1D+ngESkpqMmRZNSweFUxIcdNixxNwlVZEgGIDJGl+5lKADQ3GZ2DsbqrB1lcD3XtXghSnjjU2T4rWf/q6MqXIrdvmelKKL6HpskQaezEIFv6+A/9Rxjix/is0HJlxDiYY/ghgpSdBU0i0T3EDySHhlKeOVRnLNizlrBtYm7Ddtr0szsPnH3eAzuzpAth2EeYywCXBS4F0/CLT+2/KoOUFmTv+lczw/VCeZxFQyn4lHc8HRGQx9pnK5U36K59TwVhVS/6NA+gUra4/t9zas+cD5iXOOnrJunyEIYnwyy2IzArIUpa7oJD5D1rgoyu3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UhXDWnPkbAZNRikemxKSXUhTt6moN5yrqiyyPzoUVKc=; b=KIIwCZxbzR+3+9AoiEfFhvvm0TD7+3eMmG9wgfB5nfwdBN8poazED9XKafyr7RwyMkNE+Y2GA+beL/SC7D+T+38KwTtGULDMftWP0nf0gweqIH54igvs8y+DbisrmxzuzQ71L7POw8J8BHmpWkQjpD4mxpQnErwAU+/wUcEavTY= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from BL1PR12MB5320.namprd12.prod.outlook.com (2603:10b6:208:314::17) by DM4PR12MB5841.namprd12.prod.outlook.com (2603:10b6:8:64::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.7; Wed, 3 Jun 2026 14:40:49 +0000 Received: from BL1PR12MB5320.namprd12.prod.outlook.com ([fe80::1876:4a6d:2cf5:b8d1]) by BL1PR12MB5320.namprd12.prod.outlook.com ([fe80::1876:4a6d:2cf5:b8d1%5]) with mapi id 15.21.0092.006; Wed, 3 Jun 2026 14:40:49 +0000 Message-ID: <802f5b4b-be71-4805-8a7f-fcd5fbb70d70@amd.com> Date: Wed, 3 Jun 2026 09:40:46 -0500 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre , "Moger, Babu" , 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> <533f6b30-6d6d-4962-a7f5-b7b83d888f6b@intel.com> <81f27656-2c56-4419-95cc-54424592c1e7@amd.com> <6fc01c5a-aeee-41ea-ad02-67747ae80d03@intel.com> Content-Language: en-US From: Babu Moger In-Reply-To: <6fc01c5a-aeee-41ea-ad02-67747ae80d03@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: CH0PR08CA0012.namprd08.prod.outlook.com (2603:10b6:610:33::17) To BL1PR12MB5320.namprd12.prod.outlook.com (2603:10b6:208:314::17) 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: BL1PR12MB5320:EE_|DM4PR12MB5841:EE_ X-MS-Office365-Filtering-Correlation-Id: 968b18d6-e5e9-48dd-5a2e-08dec17e19f8 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|7416014|376014|1800799024|3023799007|18002099003|22082099003|56012099006|4143699003|5023799004|11063799006|921020; X-Microsoft-Antispam-Message-Info: t0TSmAxXnazyk46NtRnmR8DQ1ugVOMaXeC/eLmV/J7hNQVeRTrLhvYoAUXZ/fSA0cMDnE2KFyLIEU+g4IjkvyS94lZ9vgNiZW2vA6biDFkHbTZ1QsJtoCtVR6eHnmRenCv55Oe4CyUGPfgkyaMZMFDYLJNqlQhGO7/azT4f/ujq5xA5vhzKK4cuC3TDkZX9rUTX6QEdtU7IKVxTrb/D0hVLZVyAXh44f4TGFhmFXkRBvhEs0gpjfEVsYWSpDiLaKI2m/sTGcA+SohhRPnooBiKiQgrCp9yapxdeFYbZsNquzlPlDJ+nzfRYIT+bpC79riH0TQ7VS2c1WVzx2uapR+JP873HySz4TnABerzXOGUrwzZyIdfKwIFwm9MRtPmfofx97JwLGWXfDmp5rapaJDPEeb2zVxLLFwNyFhabmh2fewRxIRxijeKVBVHEeig2F/Z9f6FQunIX6xjKuKHE5mycOgcikPCIlz+qOXqc8tG8ea1lEvIMK9CQv89d0ZAUvMDfVP10+SXwLUo89bE5Iuz0xZ+sbw9HfCiJDZlixxQ/d1dDq275F+AZHrESeUc07Ga9PO/UDVPoHJT8ordRHzr892vwOUViHs7XR/f4AP1V17muPKQ45XQRBLVXZita6HhjSt2Cl1reje5JUVVL4KAXebrILETEqonL34VknAQnzqaRtbFNQniifPxUWYHS1 X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL1PR12MB5320.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(7416014)(376014)(1800799024)(3023799007)(18002099003)(22082099003)(56012099006)(4143699003)(5023799004)(11063799006)(921020);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M3k3U1p0Q0VCSHJhOTJ2WUtkQzgwbThMUjl6UzM5bVRYRlc0REs5SHRKNkh0?= =?utf-8?B?RzNNMWlkL1FBb3grWEtWZm0yemt4SytxZHpYamZDNEIrcEpBbFBHZjBMTmpp?= =?utf-8?B?dFdFSmpBUmlPT0Frek54a2I4OG9iL3g0ZHgyWFB5Z1lEMjMxTWtSUkRuc0Qy?= =?utf-8?B?WlFjSU05OGViN2lxTWdYSmFsVDY2QnU1TnFEUlNSamRVZlM2bW9HS2djdHdU?= =?utf-8?B?NE9KQXZQMi8rQVM4R0dpc1pDdXBEVlNPRzNRNFlQNTR5dGVmUWFjalduanlx?= =?utf-8?B?NmV3eGwxNzJ3UEg1OUdZOGlIRmNpQTl4MjhGTG1WRDdLSE5lcytjN3lyOVgw?= =?utf-8?B?eFBLd2lua2dOYzJGei9KZ1I0amJqS2hUa1ZIMUpLa1dZWXZROE9nVnFRY2tu?= =?utf-8?B?aDZjeEhFYzNoWVNhdGFqN3lpS0RZOWlHdFBoQXJrTTZvaU5LWU90YnpCRm0v?= =?utf-8?B?aTRucDJuOWdXN1VOejR0bGc0bU5ZSEluZGx3M3ZYdklHQkd2V1BWVm9GajZZ?= =?utf-8?B?YnFEbmxGaHV4Q1BmcGsvSWpWbWpBdTJBaGRHNE40UWhTRHFxeS85ZW1QT1k4?= =?utf-8?B?OEtBSGtwQ29NRlFrVndsVzFBWnk1MGtzMzdOVHZPKy9tai9nUEdCN0tUZ25w?= =?utf-8?B?YTl1QlVWS0dBeXdkakRCYkN0aVNlbFlkYlV3TUhUL0U3ZEh3V1dSVjNaTktx?= =?utf-8?B?RFViZTBIT0hpRkRua1lpVkdEL0wwNEFRb1p3R3cyd25IeERTNkNvcXhKM01l?= =?utf-8?B?TEhuTWFjbEtXdFBDSERxWHJhR3AzZy9NVjhaTzR2Z3U1dUc2MkNsUjY5Z0hY?= =?utf-8?B?eCtmQmlqYzgzQ2k2cUVkeGh6dVBmc1dSejRQSy9EUEhvYlhvSkc5SnJCZXVn?= =?utf-8?B?OStuRGk0Q3l2dG1wcytObldRQStNRUczaEpZRE9VcjgzaGphT2VKZGpxVWcy?= =?utf-8?B?M2R0Rzd5dTRkenpBbzA5cjQ1Q2NmaGFjK0pCMktYcmIxVGc0QUVYb2VlSzlo?= =?utf-8?B?K2dGV0VhWnVBMmhHMTlFTnhvT0c1VlpTSGw4WGo0bUtpdWpxQU4rYTlBQ2Q3?= =?utf-8?B?WEwzcERha2QrWE9SemM3bjlqdmplNERSaEgzMUJiZzh1MEZBbzdkWU9pS2c2?= =?utf-8?B?akpkZXBDTW9jYzZMMWFDMUNOSEQ4MWdTVGdvc1ROL0hZYTJyc0tFUXEraGZh?= =?utf-8?B?NHFGeGUybm9ncVFrTWhqczhSendsN1k0ZWxWN0Nid2Nra2krdVVocndsNVp4?= =?utf-8?B?Y0NNdzJYZkIrQ094dFNwbnhUTkpOS2gyNzhPenpPRHhhTDVKdU5rODJPQWVH?= =?utf-8?B?dDZxMEcwcDdobWh6QkJ3ZGVneDdOVmd6bmJsWWhvRDZGUFg1NGg5L3V0N2p2?= =?utf-8?B?Nk55T3RDYjIwZmJwdFVhY21wQnVFVC9SVlRPQWprWUp3V3dGaFV3M1JaWXdQ?= =?utf-8?B?aldhQlE3NWYvcVlQU1RmZURIaE1VTzVrSTFrODFJWllGK3NvdnJUS1ZrZE04?= =?utf-8?B?Qkd4K3drNWNkTTM0bnlqdWZxZ0NiYVBpcnV4UjhvK1Izb3BkdHkyU0cxajhL?= =?utf-8?B?Y1N2MDlSdENuOEN1ZnJxZmN3SGhaUmIyUmpxYXR4SERQNjU3UTJiRTd2TFJ6?= =?utf-8?B?SnA2OUxFYW9yb2U4TWdMVkVzbDlCbTBCQStnTU9EdWF6RDJMOGJPMWp2ZVFV?= =?utf-8?B?TnUxOE0rc3ZvTDB6aU5hZlhEYkdXSk4vZXBpYS9UM2lMZkFvT1dGc3E4a1FL?= =?utf-8?B?Yi95UUNPY1d5SndPQkxtaTJXS041ZU9NdHltYjdnL2tWdTZlaUNTeEl6Y2tn?= =?utf-8?B?OThFbkh2djJ2NlpPQlY3KzFyWm1DMDg1ak9taTVhalkvaUhVOHNWK0pJOEZ0?= =?utf-8?B?ZHZEa1pkemRHc04rVGtGK01zbW9Odnp6OU55NFdXanY5ektEeHBYcTlNZmhi?= =?utf-8?B?QzN0K0VnZUxKdzdqbm53MlpKNU1FSFhEWmZCM3AwaWJTT0h2L2d2MUpvaWJQ?= =?utf-8?B?YkRlWnMranpkYzRPNHIwN0NoQnFHRXdha3IrWTFtYUhqbDBsQzNaSjBRU3Ji?= =?utf-8?B?YTVrVVp5YzlwZTBkMWpuSExsN3BqVTAycWhOQ3QzdkdJeUZTclNwNlowSEh3?= =?utf-8?B?bERiM2F1SEY1ekloQVdOa2hZSHVyT2JmZjZqNG4zcVNubVB3L1lGZWpnRENU?= =?utf-8?B?RVZLSTh3U1lsQTcyN2hRV29QRHplaGZWR1ozZUg1VHQra01NemtnZjV6YnhU?= =?utf-8?B?S0Y5T1RDellOR1plcmtYNzgzdm5uMEk4YkN3dURaRm5MNFJaVGtVa1NmUnA0?= =?utf-8?Q?5WPoAoTt/upqjg4AtJ?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 968b18d6-e5e9-48dd-5a2e-08dec17e19f8 X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5320.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2026 14:40:48.9962 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SsE9MiFDu5j0+ZmRvISw68PilV6/NZc6hvjNefVrBwx0ovTZR3jaTFVpwRoFRVjn X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5841 Hi Reinette, On 6/2/26 22:55, Reinette Chatre wrote: > Hi Babu, > > On 6/2/26 6:14 PM, Moger, Babu wrote: >> Hi Reinette, >> >> On 6/2/2026 5:56 PM, Reinette Chatre wrote: >>> 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/ >> >> Yes. It works. But, I used to find patches using the names. It did not work this time. > > Interesting. When I run your lore query the first email from this thread is among the > results. > >> >>> >>>> >>>> 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? >>> >> >> Thanks for the sketch. It makes it much more clear. >> >> mon_domains directly maintains a list of monitoring domains, whereas controls maintains a list of control objects, each of which owns its own domain list. >> >> I was thinking, one possibility would be to make mon_domains follow a structure similar to controls, allowing both to be represented through a common top-level list. >> >> However, the resulting abstraction may become fairly large and complex, with limited overlap between the monitoring and control data structures. >> > > I am trying to envision this but it sounds to be as though each control has its own monitoring > which is not clear to me. resctrl ultimately needs to support hardware features. Could you please > share more about the hardware feature(s) this design intends to support? > This is mostly my thinking. There is no new hardware feature that required this change. We can safely ignore this idea. Thanks Babu