From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azon11010045.outbound.protection.outlook.com [52.101.201.45]) (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 0EBFA36AB5A for ; Thu, 23 Jul 2026 22:27:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.201.45 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784845646; cv=fail; b=YtIQY80ZSimsKlH0l+iHLO/AbU28ik42kV8W+TN073m6lgW+vxG+K62r6pQg4nEKRiiZtNVZuLmmFCa0Q7Ns7ZUSIkMfyFxM6V8SCJ0BfIKBw/q8EQko1x2WXiRXXoadwTaVbfE8cz+2dfRAhFdRe8zx3cXcOa4X4PVOi2xgRuE= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784845646; c=relaxed/simple; bh=HDIsUxsFEEfGl0n/hLW30hB57fM7xTueQvrZ48vAqss=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=mSTH3M/x+LixEh7Sa1mdmgPk7y0dU91khHjQQEmFnWUIHm1iLxlwzWfmyC+vfn+L7FCFdf5Rl5OSioRK52MxK6Rg/+AThKZoK1WNtGvb8HBzZFH+9jt2SQPGpq9x5jZX3AAriJSIja9quRECQP4qFeT8OM0i4cgOFQgryaWM5jA= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=bC5lrQfn; arc=fail smtp.client-ip=52.101.201.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="bC5lrQfn" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VvjKa0yLO2rF+1dCRm7wkyeMLwhBb5zQauIyfdbvYVVFV57qrTU4TuiQJlrc+yMjAVnyef+AEUP9Us7BrgqNtU+LA/XbhLieyknvFaMZwLyRitLCelQgUi6sy6fe91wpgeLfySWHdf+gi1c5elc60G3MLvjhw+eQZa4u6jH3ts3eJooIK4CRKR+rvz2iK3QiMmgG/HS/IudpgaaBSZMm5ZTa6LzyMjFy5I+JO7MK0VKEFUH51b5LEATwLsiYSpJziUblUimCA7vSitxo4r0JFHeLIqxEfjJrwVqJjG0yCr0qa2+WTllo9drJ6Bx7/CgsDVA8/IJ9ilg6PPWeDlhT7w== 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=rm7SJ+NwayNJe5kA2Gs1ZVcttxybW678qFOoz0Egr14=; b=sIQhx8n5xJ3EO1LOPHOV+HFTgHl4BugvQKoouC2AiEqp/kwJ0yH9zj3YqOZgAuduTvDwD+7C7PDIRcQsJHLX97keUwnVgJyZB9LAb3numfFRRQfVaXzFH41KYOF/752EdCZ/vxGJ9K70HPRbIadaI1QovOUSkCN71ybvAU+cqrnmAUeIJejo0fMcSjIHb9XQTNh++GuYuQqM80GKYbR4iFh0v6gs0usrfaOoFrycYjpBEz59VFdVZ9wMQJNWdDBmHvkMEcf2PNR9O6Wtea3e6kJd8nay9Voe8mVEqFiYQNa5xEQwTEVS+3MEQAijxl45i3ew35ZM9xg65Ls1R12LVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rm7SJ+NwayNJe5kA2Gs1ZVcttxybW678qFOoz0Egr14=; b=bC5lrQfnORPzp6bDW1t2AbilVplzIi7yrUBtH+gQf93mXCoQHO86lB0Rrki5C5c0tUPlUx5G1HmaTveRBj3/Y9NPkAJB+hQmxiRwqMFsqq5GjBnN01PgRifs0axq/rpqT0X/d+X5QC1FhHXrbjN/Hyw+36ad6k7cGAKhGqnwSYzn7BHLdoBhpn4JaVCD7g2h0GRRblt0+6KF7/GL5mNAl2g2TYTIcEAkKcHn240wsnIsqJRRa/CJjpHRP9soM/N5F1L1h4K3CKrSB1J2K9vydK41DxyfEErjSKvf3Y7qRPwRJQhjaHUgw2rzOgN+HS3Xfm9EonGG70FTdmntfaum6g== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from DM4PR12MB5230.namprd12.prod.outlook.com (2603:10b6:5:399::11) by IA1PR12MB9061.namprd12.prod.outlook.com (2603:10b6:208:3ab::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.245.10; Thu, 23 Jul 2026 22:27:15 +0000 Received: from DM4PR12MB5230.namprd12.prod.outlook.com ([fe80::6e87:1bde:1853:3b73]) by DM4PR12MB5230.namprd12.prod.outlook.com ([fe80::6e87:1bde:1853:3b73%5]) with mapi id 15.21.0245.010; Thu, 23 Jul 2026 22:27:15 +0000 Message-ID: Date: Thu, 23 Jul 2026 15:27:14 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre , Tony Luck , Ben Horgan , James Morse , Dave Martin , Babu Moger , Drew Fustini , Chen Yu Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <5ee87762-1898-4b62-94da-85b3e9917ecc@intel.com> <62701203-c4a3-4ec2-a9af-602e1fc15863@nvidia.com> <8f9f78dd-e3f5-4b35-bc72-0eb5dafdcedf@nvidia.com> <36163a81-9737-49e3-93ef-6c392f7272f0@intel.com> <9425e9fc-36cf-44cd-b6fd-88b76d106eea@nvidia.com> <917ef5ed-c720-4afe-aee6-3ec201e565e0@intel.com> Content-Language: en-US From: Fenghua Yu In-Reply-To: <917ef5ed-c720-4afe-aee6-3ec201e565e0@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SJ0PR05CA0205.namprd05.prod.outlook.com (2603:10b6:a03:330::30) To DM4PR12MB5230.namprd12.prod.outlook.com (2603:10b6:5:399::11) 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: DM4PR12MB5230:EE_|IA1PR12MB9061:EE_ X-MS-Office365-Filtering-Correlation-Id: 30966b47-2961-4e2a-a064-08dee9098c87 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|7416014|1800799024|376014|11063799006|56012099006|3023799007|10067099003|4143699003|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: zA46tpTg637KRPlx+uw85qGuw6PUns4ATC93dvsJX13337++B9TDuT2/sUgshM/RBBe/5D/4E89wPcO5sWRvbLAEtHMldn9HvN0i46InpDe7CZJjmN5krAwqf9IGWrYhXz4AYnNqh849YxXAWDyD+8YOLR0o7m4BVLOYdEkGLwM9gBivjPMIjwMFBQoTZdDbMdJyl7yRv1LM61NdWSrref5XlHwYg8bvYw3K4+oyPy/GmDp2swbR9+2+oX7W3ALcWawsa2MZ+vKk0iYTTS3sNahR1ocq7Z557fNNzRGCQMuN2cL+20Hda2kO7mY7vcAnjLo8yv2epUbRdFNL0EBzJoMrX5B43IFAfc22iUfPdGKz44x+uK7cEJvJ2oLhwSKVz9J0EDffOFrenvR4R7ZKV4IJjb9X6E+5pRVEcwgyBbv9JLoh8h5+e+ZiMwg8ZsCxodetfqryNuMqGpiZQTKtYW0ijyMYRWGs5vrR/M/c33rHtrYszvD8y1xvbzq7/cMk+DKWKzUZVvTt/niW3KB1QhBOeSZqkLqrTG3Jtoo+i8oYjZ76mLEMFjTkZoXQLigrzWCKidU2axYTPDDtsuH+KAbylDKxn3TOGPp9OFCWBjUjdX0AfSiP0soA9s77SZR4CqvdCZHXwmdVS/GirOihx2FaagfVlARtD+7xd3NTLZY= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR12MB5230.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(7416014)(1800799024)(376014)(11063799006)(56012099006)(3023799007)(10067099003)(4143699003)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YUpMS2plYmJ3VTBDK0MrSjRxRG54VElYUFBaa1NybUVQVnB6M2E2aTA5Ym5w?= =?utf-8?B?VTRtY2tkNzkzZXpmdmRmQ0lVV1Myb3plSnVwdjl5d0prdVpvREJKWFJ2Wk9N?= =?utf-8?B?TnNEUFF1ZzY1Nk45VlE5aGVHbDJCTlhOWlNHQ2ZxN3VaY05kUDVwZWtBalhZ?= =?utf-8?B?U3NmZmZtajNOVkswY0N6MHlTSEZaZmd3eXFCQ2tOWkc1WVA2cUtFMUdLQ1NW?= =?utf-8?B?Y1dWYmt5WXF2RFROdFFDcjhkVG10UkJzcjE1ZDE5STJJSE9sRjdNeExXNEVi?= =?utf-8?B?QTY3WmVkbFQzeUdGeVovRXZvd3cyamVaK0ZrdXFyWUhrVTlTYUl4N3NlTktR?= =?utf-8?B?d05qUUYrRGdMOHpZcUNXN2ZBNkNRMjV1dXFmRWxkdkNuVnVzSzBjV09NMGlV?= =?utf-8?B?N1VYQW90UFNZdHJRc3ZwTVEwN1ZUTGJTZ1Z0K1daNjl0NTE4bytmbFpJRW9D?= =?utf-8?B?UnA4aTNGQXk2RVR4cFdVVmpodjcwTmpOTDdwank4K0NPWkVvdTVpUmxNQXBO?= =?utf-8?B?bnMvbkMyM2hhUmZzbU1hZmRlU2p0QjdOc2l0d0ZRcm1MRXhxNW5hNWN0SXY0?= =?utf-8?B?SkNyQ0V3UDBGc0paWkpWT3NEcHU1dUF3MWcyTFZ6WnpSVHcyWjhydFUxTDl4?= =?utf-8?B?VW5tbnlKdkkzbCtZaVpObjhsTHVVM052V0IxS1ZOa3pXd1pzbUkweGhEZ0tV?= =?utf-8?B?MXJVMTFjd3ZIb0o4d3pseE5MUXQ2RDZaN2xlNGtPOTJUcDZjb0VWamdxeWVv?= =?utf-8?B?TGlYcHBHT1R5ZnpITTl4V0NPQTNxbjlzbVdNNStpZlJEZlliYmpyckdnT3hm?= =?utf-8?B?ZmxHT1AxNFFQcjNsSE00RVBRZ2EvaWxZUElPbU5ScnUrNkQ1ZTZtTWQ3VGM3?= =?utf-8?B?YW5tNE83aVZXT2FwMFF1d0F3bVpZVnFFVjdkT0p2UnJSUHpIWjlDRTB1azdo?= =?utf-8?B?dk40UWFLclhtTHk0aTlOTlVHcHh1VzhndzBwZ3VEVmZUeHREeTdCQVRFVHA3?= =?utf-8?B?TERIb3pNVnJGY0ZKMWxuK3lmMml1SlJqVVlsQzZUN2hvbGZNd014WFRGaDdm?= =?utf-8?B?UUFUclVhc3A5WDdoS2NieFU0RDdPOTBnWUx2cjFxMGxwdWFUZHExQTMzMmhM?= =?utf-8?B?aUduWUFhVDE0SXpveFdrRGJqTmFaN3BuZE1PNDlLNkdXck5udGhoZXBLdmtQ?= =?utf-8?B?a2RwK0NYb1FTZVFPRVE1Yi9ySEZIcy9RcjJrRzcwajE2UFA1QXRyeXlpUlhP?= =?utf-8?B?d2Y5WksyOW1keGZHSkxnZFluaDJXR2ZwVWI3SmozWk9XTHNaeHc2MFJZRTBq?= =?utf-8?B?YlhRSElubnVvY1BubTVkK2xNL21nYUNQaFYxN0ZjS2p1Ti96L2t1Qm1seFU3?= =?utf-8?B?SktnZElvcHNsU2Q5Vko4d3ByeDNBWFp1V1pFdStpYnkrV21TNFR6QTRxTFpl?= =?utf-8?B?ZVJGN3dvUDVUTjMyUWgzcjg4c0R1d3lLeSszNEVySjg3K3FzSG04elhSdlFM?= =?utf-8?B?QmJxOXpObUQyTnhLTHV5dXFMTjBHZk5FMmcxcXN2VllCeENKMVhYeHg5SndO?= =?utf-8?B?WmV3OHhMNWMvbHQ0N3hOZHExUU1kQkQzcjFyZjM0eXE4bThlS3hCY0dPV2tI?= =?utf-8?B?K2Y4b0ZMZTBCcVNDVU9KWlk3VkVSd2QyOVJES2I4QUlNTE9FOEpZK28wcUZX?= =?utf-8?B?WFdYZjNmbWZxa3NHYXJCOCt4QWlPUEJoam1uV0NQSVE0NWlyQ3NGWlJ4SG9k?= =?utf-8?B?djdEVFBSSW9ZelVLbmRsN1dzU3R1THlPbFk0cC9ScWtSU2lSY2liMzI2NHdR?= =?utf-8?B?WnpxSjZrVU4wRmJuZjMrcVdDRTMyL3dZZTlMMDBVTVJTd0I0Zmx4b0RqSFI0?= =?utf-8?B?dmtTQytkOXZ6WHVJbEN1Z0RiWDdLejNwYng1TW5EM1REejdTa0ZiQ0Q1aGFa?= =?utf-8?B?WEI5TDRsVUNzcjYzWE85ZlhyckQ5ZkV3cTVZSmNPWWFzSEFsWGZ1eTUzOHRV?= =?utf-8?B?L3h2QlRjaDVJNTlXNndiNnpYVGJoTTY4YjNWVDdneWNIb3JReGVWQmZ4VVJY?= =?utf-8?B?dVRCMHpSa0lVR1hKdnBpbTlWQk5PeXg5RXZrL1VNS05DZFg2eXcwZ2llVFo3?= =?utf-8?B?Ni9MZUdNT1BDamVIbVgwYVNPNFVNc3J4L0JZRUZ2R01DVXJ2Nzh3UU81WkZ2?= =?utf-8?B?dm5xNnFnK3BlZHpqVU54V08xQUVuaCszQm9sYzNvM1M3YnIwOEMxYjdEdFZJ?= =?utf-8?B?VW1WKzVXSGhucEw4Z3JCK1VwL3Z1b1pxSUY4VTZtOUc3ekh5N1U4TlA3ZVdp?= =?utf-8?B?UEtTb1MyMjRkM0JycmJrcXMzOWVPV1VpalVweEtjcWNqaHQrcEdKdz09?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 30966b47-2961-4e2a-a064-08dee9098c87 X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5230.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2026 22:27:15.6616 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: r11Lr2R/svKS9LzuOxJtK2ERJ3fAEdHlTtwOKPlhEc/L5PnmtlDrdew0Y+pgyHWotx9+a7Ub3JCA9ptGng2wXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB9061 Hi, Reinette, On 7/23/26 09:18, Reinette Chatre wrote: > Hi Fenghua, > > On 7/22/26 5:17 PM, Fenghua Yu wrote: >> On 7/14/26 15:06, Reinette Chatre wrote: >>> On 7/10/26 1:59 PM, Fenghua Yu wrote: >>>> On 6/25/26 08:43, Reinette Chatre wrote: >>>>> On 6/24/26 6:26 PM, Fenghua Yu wrote: >>>>>> On 6/24/26 15:22, Reinette Chatre wrote: >>>>>>> On 6/24/26 12:08 PM, Fenghua Yu wrote: >>>>>>>> On 5/29/26 11:06, Reinette Chatre wrote: > > ... > >>>>>>>> 2. /sys/fs/resctrl/info/MB/max_lim >>>>>>>> It shows number 0-3 for MPAM MBW max limit behaviors: 0 for supporting both softlimit and hardlimit, etc. >>>>>>> >>>>>>> Again this adds another *global* property to the MB resource but then above you >>>>>>> describe the new "MB_HLIM" schemata file entry that implies that it is a new control >>>>>>> for the MB resource. Having it be a new control for the MB resource matches earlier >>>>>>> discussions. To support this I thus expect it to be exposed as a new control with >>>>>>> potentially a new type if any of the existing planned types do not suffice. >>>>>>> >>>>>> >>>>>> How about adding these MB_HLIM dir and files in info? >>>>>> >>>>>> /sys/fs/resctrl/info/MB_HLIM/resource_schemata/MB_HLIM/type: boolean >>>>>> /sys/fs/resctrl/info/MB_HLIM/resource_schemata/MB_HLIM/max_lim: 0 >>>>> >>>>> This presents "MB_HLIM" as a *resource* to user space. It is not a resource >>>>> but a *control* of a resource, no? I thus expect it to instead look something like >>>>> below that makes it clear that MB_HARDMAX is a control of the MB resource. >>>>> >>>>> info >>>>> └── MB >>>>>       └── resource_schemata >>>>>           ├── MB >>>>>           └── MB_HARDMAX >>>> >>>> Yes, this makes sense. I have changed to this hierarchy. >>> >>> Thank you very much for considering this approach. >> >> [ MB_MAXHLIM: I use this name for MBW_MAX hard limit feature as Dave Martin suggested before. He also suggested MB_HARDMAX. Either name is good for me. I use MB_MAXHLIM to explain MBW_MAX hard limit for now.] >> >> Some implementation thoughts: >> >> MBW_MAX hard limit itself is not a MB control. Rather, it configures >> MB control, i.e. turn on MB control's hard limit or turn off its >> hard limit. So MBW_MAX hard limit doesn't have properties like >> bandwidth_gran, delay_linear, etc. MBW_MAX hard limit's property is >> only a boolean type. > > "MB" is becoming more and more a software concept that represents memory > bandwidth allocation and in that sense I agree that the "hard limit" is not > a "MB" control. Even so, since "hard limit" needs to be exposed via > schemata file it is *a* control. This is because as part of exposing it via > the schemata file it requires the following: > - a "scope" that specifies what the "domain ID" associated with this control in schemata file means > - "domains" to be the list of domains, one per "domain ID" from "scope", to contain the > staged values that user space provides when making changes to this control > - a "name" that is presented in schemata file > - resctrl needs a way to pass the user provided values to the architecture for > programming, the API for this is to pass struct resctrl_ctrl. > > You are correct that none of the current control types are a good fit for this > new boolean type. resctrl would need to support a new boolean control type. > Ben and I recently exchanged a few ideas around this. Please see the thread > that starts with the message below (search for HARDLIM in the message): > https://lore.kernel.org/lkml/34b95afb-8b60-4680-9ad1-90c5b24e8fb7@arm.com/ Yes, I had some input in the thread. > > >> >> So I would think it maybe a configuration inside a control. >> >> Similar configurations could be hard limit for cache capacity in MPAM. >> >> Maybe can add "configs" inside resctrl_ctrl. Schemata and info/MB/ >> resource_schemata/MB will show/write the configurations per control? >> >> For this configuration or future configurations, add "configs" list in: >> 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; >>         struct resctrl_ctrl     *emulated_by; >>         struct list_head        configs; <--- Add configs for this control >>         union { >>                 struct resctrl_cache    cache; >>                 struct resctrl_membw    membw; >>         }; >> }; > > As I understand the idea is that configs is a list of struct resctrl_ctrl? Yes, it's a list. A control may have a few configurations. Currently there is only MB_MAXHLIM configuration in the list in MB control. A list may be expanded to future multiple configurations in one control. > > At first glance it is not clear to me why the additional layer of abstraction is > needed. What do you think of Ben's suggestion in thread I mentioned earlier to > instead name the control: > "___ where is HARDLIM" > (nit: While I understand HARDLIM matches more closely to MPAM spec I do find > "HARDMAX" easier to understand) Yes, add the name HARDLIM is fine too. But the arguments for adding this configurations in a control are: A "configurations" is different from a "control" in that: 1. The configuration configures the control, e.g. toggle hard limit on MB control. 2. The configuration doesn't have the control's properties (e.g. gran). 3. The configuration is similar to "event_configs" in MB_MON, that can also configure MB_MON's event_filter. So distinguish "configuration" and "control" might be more hierarchy? Adding the config name in control name doesn't show the hierarchy of the MB and its configs? > > The additional layer of abstraction would require both resctrl fs and > the architecture to dig through two lists when handling these controls and it is > not clear to me that this is necessary. > > >> A resctrl control can have one or multiple configurations. Currently >> MBW_MAX hard limit is the only one. But the infrastrucutre supports >> multiple configurations per control. >> >> schemata: >>         MB:1=100   <-- MBW_MAX on L3 id 1 >> MB_MAXHLIM:1=0     <-- turn on/off MBW_MAX hardlimit on L3 id 1 >>         L3:1=fff >> >> info/ >> ├── MB >> │   ├── bandwidth_gran >> │   ├── delay_linear >> │   ├── min_bandwidth >> │   ├── num_closids >> │   └── resource_schemata >> │       ├── MB >> │       │   ├── configs >> │       │   │   └── MB_MAXHLIM >> │       │   │       └── type   <--- bool >> │       │   ├── max >> │       │   ├── min >> │       │   ├── resolution >> │       │   ├── scale >> │       │   ├── scope >> │       │   ├── status >> │       │   ├── tolerance >> │       │   ├── type >> │       │   └── unit >> │       └── mode >> >> >> Is this a valid way to handle MB_MAX hard limit (and future more configurations per control)? > It is possible but it does look very complicated to me when compared to using the control name to > express relationship between control and configuration. This configuration is similar to "event_configs" in "MB_MON": └── MB_MON ├── available_mbm_cntrs ├── event_configs │   └── mbm_total_bytes │   └── event_filter ├── mbm_assign_mode ├── mbm_assign_on_mkdir ├── mon_features ├── num_mbm_cntrs └── num_rmids So it's not a brand new info hierarchy. Both of configs change a resource contorl/monitor. It's just for "MB" not for "MB_MON". What do you think? Thanks. -Fenghua