From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH7PR06CU001.outbound.protection.outlook.com (mail-westus3azon11010028.outbound.protection.outlook.com [52.101.201.28]) (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 52C652DA74C for ; Mon, 10 Aug 2026 02:55:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.201.28 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786330549; cv=fail; b=J7+ntJBEaFt54TBZ/gtJr+OCDMuPoQUvWRkC1fPxY1fI4uL70WekaJGYC5h0smubrbsicarI+LcyenAJNHQVfmYA9DRDfioekn0RBn+UA5MCprUTG+gzXIjK3OAv59/3BSM+62Mq7QsPUVPJDrOWw7gzwOm+c/BsJ1dFA7M5ZKk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786330549; c=relaxed/simple; bh=+r61JKRwsXU57LMg2ydWBy7tFp5EbFMVSj69U1G6IOo=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To: Content-Type:MIME-Version; b=YyMEyW38D2xLjE//qikSgWUc0Y9Ml0kDUcEZYdnBLPyQRdhFQrJqj1qlPGQMlNUU+jMJxdCyGnco8F7ypuR3B0mtH9xy73XbCEunmehIKmf5Z7juGoFozKdvWz84O+NufAyyo/4A2AwDshGCzc6lRyx6DSEHsBj8sgE/PGOp4XA= 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=CTdpYVnM; arc=fail smtp.client-ip=52.101.201.28 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="CTdpYVnM" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=CCX1MAbxo6Kt0vLSRUXeb2mdknwUHIoyJQoND6iN3WD/wrk/GV+iUQtKxqgCPObYnaty5gK9gX3S5uTBkpaLnenI6wxSN4d13mgOvqJ7ltd9lptC/GXQ9N7ATXhIDuE/2toLOzoqFFVLbou/bE++Gli0OFL87ek9nGvhQ/b6k6mfZgQqj/Llh3ocuYKvNnrmG7qmHh6TUW9C8cggyVtJTbqnkwm9xZsV9Bvi7bRWBdOf8khlEuiR74wsqvfFnyT6sum37CnngplqGdVLJMe57qbSmcy4bYdjM7ABFFQj4ZoxcA96tFJrqUzxpqdjUNmfEZb0iQ/R8V9WTgNookdphg== 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=57+qhEZQCtMp559xmdK77Qc0pgByWfaBT9BL79aqHg8=; b=Ym5c7J995xCH29JNiWkky91N8LbO/Q3oq/XqqiHt8w6lmV2rm2Ec/L7OfbmlcByLBtqzjBThxLt9c28PQCf32DkTdQpCsVap5ZdAPJYF6/x/vjtDardLKOUk9Kq58EC9fiKX6b4IomryY0MTGwfu62YZaPHxvTvMSi4qmK4wYThCnhxAepmaBpo+22l+6zmKZ4ayfBqfjRzCjGf+w8THW91eHS1Nlgjptdfmh/ZREeIixp/8hIvN9sUkfmDCVY5dSX4b+nEbtwk1Tycg0Er7iiGYto+m41JPHmjC9q3tYRvtbpGsxWFbbROKMJd+tapelwyS0+UeEEeniltB7z6iIA== 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=57+qhEZQCtMp559xmdK77Qc0pgByWfaBT9BL79aqHg8=; b=CTdpYVnM0r2LyGldQK3N+Fk57YAxxOziqjqz7coj/T4ERaIF8ZoV9CUuOtzqvMM5t1ldFRBHJbFn1IfOH793IsMSuBmJqwRfuWFq5ZeJVgGaGd+wHuE+5wfmmkcR3+qSqjbCTYa4aFHB/+cCNVqyW+IpkvcRotr1GHzy39UvbRqFFRa9vJz0ZkZk542Hqau2CUcMTs6wwgyGdbBvOucg9f8dOyyUdVoNnEwzU+g23bTgs4CypyaPMMhk1gaoz0pRCfDWHakKEK/wG310zEJHaQrejqDAxJzrGwT6q90KY9YTqYtoG4kq4rBwibbhQvZ+GXz4rMEAnKKCekAnf1QZmw== 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 DS0PR12MB9347.namprd12.prod.outlook.com (2603:10b6:8:193::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug 2026 02:55:42 +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.0292.024; Mon, 10 Aug 2026 02:55:41 +0000 Message-ID: Date: Sun, 9 Aug 2026 19:55:39 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2] arm,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: Content-Language: en-US From: Fenghua Yu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SJ0PR03CA0105.namprd03.prod.outlook.com (2603:10b6:a03:333::20) 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_|DS0PR12MB9347:EE_ X-MS-Office365-Filtering-Correlation-Id: ae42f554-9404-4df4-5079-08def68add44 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|7416014|1800799024|376014|18002099003|22082099003|56012099006|10067099003|3023799007|5023799004|11063799006|6133799003; X-Microsoft-Antispam-Message-Info: BO6jDEWdEAo28pi7TEvq6lSevdFMDgg+3f31rQNodAS22UkJNFY5/DP3qsLN1y6xO2l4jc+7Yw0B/7qhYQOnHI3023+zd2kzuNcaQ1HYT5Mrw+0s23oG1+jm154FNxqBxjhNXFhORLGgVSrvDdimVUctRsSiL2QjFAa/JUWLv1ZSYZ+JjnBgiK4uinDTQs14kDfwgYS/SnI16qL5F89+1D1qizF3crnnZqF2FpARbj4LrY0z+X34MaR9pG7T9B/3GyFaXCPcrIIu7mj+R1aD2sZ0WFhJFwCSOVS6JDeCoVc8wMeQlNVxPmzmZw+Gyi0rg3J2I9EOHwDbffRouUknsNb6WBinkI6LCuIhrscihFsA6nChdMeHSul+8Vg3WiFRy8IIwM/mJ+955v62k+dIFHt9J0/A6M8eHP4l7YTVZXVNjJ6FCQYxTi2Kh8EeqWBl1YNOQ9Qg+qRHcswBpVDQb355DlXr335GLiR5wYLgSgRDiLqu4TOoRWDd+ZT8bowrooJ+VKChMfh5N6ABDTeWQHGYRk5iFG/x0HeTZpFb414x+Zy7cdGf1HpHvPmbmylUKJu/zDTdplZJcw5pLcOpPcvEd2XFV9wdpb+l1EcQh2UWnqr+891XkEtgV4un8ndOKKZvTJVF8vOdOZbvqv6SwZ0SxFNBFFgmmndseY00Txw= 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)(18002099003)(22082099003)(56012099006)(10067099003)(3023799007)(5023799004)(11063799006)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RXdsODVvOGdlTzFFbGlGelkyVDRNRTkvb25NNDNLUk5wQjZtUEN1bXdsTElz?= =?utf-8?B?K0ZoMG9jcnZpenJYR0diUVpnMW1CRjdxQSs0d3lFZ0swdHV1Y25LU1Mra1Ez?= =?utf-8?B?OEJtdkYzWGx0QzRJMFd6WmRtWS80SSs4enhvUWtFTG1WOWIramNrMDM5dzlv?= =?utf-8?B?QWpCQ0xHUjBpTy90czlmeEl6cTBvNGI3THZJN0g0aU1kMjErNzdObHEwZWtU?= =?utf-8?B?Ukhvb3FhM211cTA3bzZxRHp1NXJkblBZbGhYa0tJQ2s1dWNkWmwwb2NIbndw?= =?utf-8?B?cHpwM3dWRGdoSU56ZWVjdUF2OWZOWis1UmlwUHRoQmU5Yi9VbllSLzBxNGlo?= =?utf-8?B?ZGV6ejZPZU45YXFMQ0N2bmMzRUI2cDl2dWp5VFJ3L1F3WEw4YzY0aWV1T3hj?= =?utf-8?B?WlNOSlBLdVNYelFKWlBIdERUQjliUVBvTlRrN1NUbVdGbXNvelJ6ZC9SVmZy?= =?utf-8?B?R0JUdWJqeG9hNExWd1oxUExFdCtnS3ovdHhFTTZPZHRSVjEzbk50dmxVdnFU?= =?utf-8?B?bG8wOG8wa0VVejJ2Zjh1akNKSGNUQ0hhVzZKdUh3b2JTdERwQ0wyKy9JVHcx?= =?utf-8?B?QVgwZFBIbzNaWlEzakVzanRScElETXQxczhxenJTMloxbmR1MnZkZWVBQzJ1?= =?utf-8?B?eEI4dDI2ZVJuWG1id1d6T3ZqN3RBeG1VYytnUTdSRjJWOHliMHVIdDVYYU5L?= =?utf-8?B?c1I3bmFmd0Z3WG1nMjI2MkttL1BVa2hHeEFMdGkxRy9EWmh1UHovNTdMR1hN?= =?utf-8?B?aTNxQTR0eHExbGR2b1U2NFl6YklxUHNDbXhnOHNtQ3ZEWGdWbzd6Nk9UUFJy?= =?utf-8?B?NXFhb1Bsd0VyZzIrOXNsUEJJUkluNTlnQWpkaFlPVW5HMmUra0JJeEU1QVNz?= =?utf-8?B?cUd1WnhGUGZ0U2pmS3ZsU3FLTVg1ZzcxU2N6S2lxMzBEcWFzZjBJKzNpOHpG?= =?utf-8?B?WVYvVFBLQmhSRmNET2wrMkc0Q2RpaEFIbmcxdnNyYTNLNnBUbUcvUjJndnFQ?= =?utf-8?B?b2ZpS3A5RXk5dkE4bzQ5RmJxUVZYMXFSaGs4ejQwNUxaUkhKNGpsQ3ZPMUZm?= =?utf-8?B?ODFtNVFwSXVxSHdJeG1yUWROUWwxZ3duMVJIQm1heHE3MSthelhOeElUNnhF?= =?utf-8?B?bkdxUHA4byt2V3p1TUg2VXdXend2cjdIMUtIdEtoY0pkRytPWVdLbUlvVGF4?= =?utf-8?B?VmRHRUx4c0hOaXZjdmVDNEVkK3lrdWRaL0ExbkE4N3MyRG9EbmZNNmR2R3M1?= =?utf-8?B?Q1pONHhXaUNYYzJhMVlnbmJEVndRKzdzYmo3T24yRkttckl4RXJmWmpSL0NQ?= =?utf-8?B?WFpTN1V6ZThVL0M2V2Zub1gwQWJSRG0zUXN3V2pDU20yKy90SlowcWp2blUr?= =?utf-8?B?aVVUQnRLc2dkdEc1OEJXOEN5M1VxR1U1OFhERUJqMmNSNUFhSy81TEQ3UFZw?= =?utf-8?B?a2xKZW5ZekxpaUNOR3U2Z0VROUNxUXl0a3FYeWR4RTk4MEcrRUh6bm5NTmZW?= =?utf-8?B?RXR0MTh1a2l1bjJoMStXUWZoUVVtVnd3TlFaUmVZL3ord3QwZEJmODNoL2h5?= =?utf-8?B?VGpCdlRDRUdRckhmcWxWRVhOYmwvMnB6UlZjVXBjN3V1YnAvSWxNNzY3c1Vv?= =?utf-8?B?bmdNdlRxV1JsYjkyRVRmVnVuTHEydUVVSlJGb1A4TEdoM1pMTDlYUkp5YkMy?= =?utf-8?B?bk1YdFpMbFlFNHJQdHp1S2Vvd3hWRGt0UWhPL2xtckpRYkZzd0hHKzNzYVRr?= =?utf-8?B?YVUvNzRTN3FJM3hDOUNzeGFMMGU4dFpEaTQ4MFpxM3VGelBTdFJXZjQyMTg0?= =?utf-8?B?S1Y1V1Z5VHo4UFE2SVEzclpDellkd3Z1cVlkM0oybzBTdjhnR3NCdnJ4ZHVH?= =?utf-8?B?QmV0TmV3SmV1bE95K2lEUlBFbDd3RkMza2xQL0hOV0JhY1ZIMVBzL1FlRWJR?= =?utf-8?B?aUVkVmR6QUoxZlIyR3kvOE1hSk1OVUZPYUxiQ0NsaWIzUnBhTHF0a2pqL2xz?= =?utf-8?B?T0I5M1hCb3VqZENZTi8zNXRLdCthRDE1eUxIbXc0ZlZBRjUwSi8zbjlObUhu?= =?utf-8?B?T2lxYThpSjN4U3Z6UVljdW0ybm9GbXdRcVBYeGJ1RXJaV3dQd3pNZ0VHUGov?= =?utf-8?B?R2tJZzkvWUs0K2dQRFREcGpkZFhHdStXRjRseTV6R0FMNnJQMklQMUxDR1pS?= =?utf-8?B?VFk0KzFEWnZ4SWR0ZnFBZmlwbVNLelpjUktCRDY2S3N3eXpyaUVXTmo5Nm5l?= =?utf-8?B?NEQ2bXFSeWpJbC83T3pRQXdpU2xaVG5Eb3l4Qi91VHFzbzluenVPZ0twTTUr?= =?utf-8?B?Q3ROdWo1U3E1QWFvdHQzN0U5RkwyblFZb1h3TUxFSWsrY24xbkU2dz09?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ae42f554-9404-4df4-5079-08def68add44 X-MS-Exchange-CrossTenant-AuthSource: DM4PR12MB5230.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2026 02:55:41.2729 (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: CT3yhIbYLwirCqcYNh8xRUypp4t4pjEEKFo83AdATiXfhEUVjaS33FTKHpYhv4ZDhZDuJKkkFjQOWAdHYOaBSQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB9347 Hi, Reinette, On 8/3/26 22:26, Reinette Chatre wrote: > Hi Everybody, > > I understand that folks are eager for this work to settle so that features that > depend on it can make progress. > > I do have a request if you have a feature that depends on this PoC: > > Please do not fork this PoC and keep changes to the PoC code in your fork > to meet the requirements of the feature you are working on. This is resulting > in duplicate (even triplicate) changes to PoC floating around. Instead, > please collaborate on this PoC by responding to the patches that need changes/fixes > to support your feature. If the patches do not exist yet, please participate in > the discussions that plan these changes so the work adding the discussed features > is not duplicated. If you already have the code, please feel free to send as fixups. > Doing so will help this PoC to settle faster and help meet the requirements of the > feature(s) a couple of folks are working on. > > RFC v1: https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/ > git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v1 > > RFC v2 of this PoC can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v2 > > The list of changes is long. For an overview of the new interfaces, please see the new > documentation patch: > https://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git/patch/?id=2e2d0140e857eae2ba3e71e8d9c595897649599a > > Remaining Opens: > --------------- > - MPAM only compile tested. > - Only "SAMPLE" code provided for x86 to demonstrate emulated controls. > - Architecture should take care to restore control value of legacy control when > switching mode from "native" to "legacy". This may be complicated by a > legacy control backed by multiple native controls and thus best handled by > architecture. This adds a complication that resctrl cannot promise that > switching between control modes will not be destructive since a reverse mapping > may not exist. > - When switching control mode to native the top level control info files > stop returning information. This could be considered "work as intended"? > - Add relationships between controls. For example, cannot set "MIN" control > value to be larger than "MAX. Unclear how to do this in resctrl fs when > considering that the relationship may span between enabled and disabled > controls. This is potentially something that needs to be managed by architecture > and thus potentially without a consistent failure to user space. > > Changes since RFC v1: > -------------------- > There are many changes since RFC v1 since I aimed to address all feedback > (but please see the deferred/dropped list below). If I missed anything it > was not intentional. Please feel free to point it out to me. > > User visible changes: > -------------------- > - Expose bitmap control properties to user space. > -- Only expose two properties: > - resctrl_ctrl_bitmap::min_cbm_bits exposed via new file "min_bits". > This drops the familiar "cbm" term to not make the control specific > to capacity. > - resctrl_ctrl_bitmap::cbm_len exposed via "max" file > -- While "shareable_bits" is technically a bitmap control property this does > seem an opportunity to deprecate it since the IO alloc support proved > that it does not accurately represent shared allocations, "bit_usage" > is the best for that. > - Add support for control flags with "linear" as first flag of the "scalar" > control and "sparse" the first flag of the "bitmap" control. > Include flags in output of the "type" file. > Suggested by Chenyu: https://lore.kernel.org/lkml/90ae82da-02b2-4058-8c1e-f16df3226d8a@intel.com/ > - Add a "default" field to a control using the "reset_val" name suggested > by Drew and return that instead of always using "max" for the scalar control. > The "MIN" control can return its minimum value as default. > Suggested by Ben in https://lore.kernel.org/lkml/29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com/ > Use case from Drew: https://lore.kernel.org/lkml/aiCBratZchVFVhws@gen8/ > Drew suggested name as "reset_val" https://lore.kernel.org/lkml/aiOrznnZjTGywMna@thelio> > - Change "resource_schemata" to "schemata". > Fenghua: https://lore.kernel.org/lkml/d0f84cef-58f5-4b84-8171-a0dfe8fa6829@nvidia.com/ > - Fix the control alignment. (Chenyu and Tony) > - Drop the "per control" scope. Move the "scope" back to being per-resource and > do not expose a per control "scope" file. This helps to support new resources > like node scoped MBA that cannot emulate the legacy MB control. Also > supports emulated controls by ensuring that all controls associated with > a resource have the same scope. > - Support emulating legacy control. > - Support multiple backing controls for a legacy control. > - Expose new per-resource "control_mode" file that user space can use to > switch between legacy and native controls. Only the enabled controls > are shown to user in schemata file. > - The new "native" control mode is only supported for the MBA resource. > The solution is generic but there are implications for, for example, the > resctrl features that rely on the legacy cache control (cache pseudo-locking > and IO alloc). Defer support for other resource since there are no immediate > plans to have, for example, the legacy cache control backed by something else. > - Architecture differences imply a lot of architecture flexibility in > support for emulating controls. > Architecture can expect resctrl fs to only stage control values in > controls that are enabled. Within architecture there could be rules > that determine what to program based on the control's emulated controls > or it could dynamically program update callbacks when the user changes > the control mode. RFC includes sample code identified by "SAMPLE" for the > latter that demonstrates one way to solve the x86 variant where the hardware > self supports both legacy and finer grained controls. > - The top level legacy control property files stop returning data when > the mode switches to "native". > - Draft of documentation that describes multiple controls and emulated > controls. > - Fix Intel MBA tolerance to be 10 to match the "round-up" implementation. > > Changes not user visible: > ------------------------- > - Rebase on tip x86/cache with following applied on top: > "x86,fs/resctrl: Improve resctrl quality and consistency" > https://lore.kernel.org/lkml/cover.1782857711.git.reinette.chatre@intel.com/ > "x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch" > https://lore.kernel.org/lkml/20260709093111.367851-1-ben.horgan@arm.com/ > - Fix initialization of controls list in MPAM. (Ben) > - Dan Carpenter reported an issue with missing unlocks in > rdt_bit_usage_show() that was resolved as part of rebase on top of the > new info_kn_lock()/info_kn_unlock() helpers. > - Drop "mpam,x86,fs/resctrl: Make memory bandwidth delay a resource > property" so that memory bandwidth delay linear flag can be a control flag > instead. > - Separate adding the control to struct msr_param from the change that > makes hardware update functions part of control. > ("x86/resctrl: Make control update properties part of the control") to > create new patch that is moved earlier in series to support bandwidth > linear flag property being part of control. > New patch: "x86/resctrl: Include control with information controlling hardware change" > - Rename the controls to match their type to reduce confusion. > Suggested by Chenyu: https://lore.kernel.org/lkml/773353e8-b2a7-4c20-b6fa-195b0b301107@intel.com/ > New names: > struct resctrl_membw -> struct resctrl_ctrl_scalar > struct resctrl_cache -> struct resctrl_ctrl_bitmap > resctrl_ctrl::membw -> resctrl_ctrl::scalar > resctrl_ctrl::cache -> resctrl_ctrl::bitmap > - Switch subject prefix to be "arm,x86,fs/resctrl: ..." when changing both > architectures and resctrl fs code. > - Switch to MPAM subject prefix of "arm_mpam: resctrl:" when only changing > MPAM code. > > Changes deferred/dropped: > ------------------------ > - Let "scope" form part of the control name. > Drop this since the current plan is to have the scope be part of the resource > name for new resources. > - Introduce new per-control "status" that can be "enabled" or "disabled". > Drop this. While controls now have an "enabled" or "disabled" state internally, > this is not exposed to user space via a file. Instead, the "enabled" or > "disabled" state is exposed to user space via the entries appearing in schemata > file. This simplifies the subtleties when the hardware self supports both > legacy and finer grained interfaces (aka RDT's region-aware). > - Defer emulated control support for cache controls. > - Supporting different monitoring scope is not part of this PoC. > > Any feedback is appreciated. With minor MPAM changes, I can do simple tests on MPAM: - INIT_LIST_HEAD(&hw_ctrl->r_ctrl.emulated_by); + INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by); - INIT_LIST_HEAD(&hw_ctrl->r_ctrl.emulated_by); + INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by); There is a branch resctrl/controls_rfc_v2.1. Seems no diff from controls_rfc_v2. Is either branch OK for base code? * @emulated_by:List of controls that emulate this control. When set the containing * struct resctrl_ctrl is likely a legacy control and @emulated_by * are the finer grained hardware controls used to back the legacy * control. This emulation is hidden from user in schemata file when * rdt_resource::ctrl_mode is RESCTRL_CTRL_MODE_LEGACY and * exposed when rdt_resource::ctrl_mode is * RESCTRL_CTRL_MODE_NATIVE. */ struct resctrl_ctrl { ... struct list_head emulated_by; }; Does this mean a legacy resctrl control can be emulated by a few resctrl controls (which is stored in the list)? e.g. legacy MB control can be emulated by a few controls? I thought "MB:" line is emulated by only one native control. e.g. "MB:" line is emulated by "MB_NODE:" line. Thanks. -Fenghua