From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from BL2PR02CU003.outbound.protection.outlook.com (mail-eastusazon11011054.outbound.protection.outlook.com [52.101.52.54]) (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 34EFB35B657 for ; Mon, 15 Jun 2026 21:05:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.52.54 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781557542; cv=fail; b=mOq0p/XSX5aLiYpD6s9N8USCPkGMmRmsY2/cwisMM7w9I5XD4bdIj3FkumP6KVBe4oH9hgKI3lIQZg2lhoyYI0v2sLivucJ1Ebk1dyYzEdqb5vM/18Q6nfI+26LMS6yteIMbgEvNziHCjvAV/Q2HFrpVbVtKuY36DsRoiKrOWMQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781557542; c=relaxed/simple; bh=IZGaxYioNhhr9HKEeH+DnFbUuUS690sa9VqLkXxOZok=; h=Message-ID:Date:From:Subject:To:Cc:References:In-Reply-To: Content-Type:MIME-Version; b=Pv/4/Mr42c8HhKz4tEInE8f5ezPGUhVB4gDpkN0T9TmdckrGKdJhz9w8DznwvqsOiJCz4Qa8ECxVo1jjepV/cvcdxlsAGn7z21zXyYZ7yM6DFEy7CEgP7u/WVkI7ZQF2rKrK/qVKefpY/847lt6RpRnzmscTGn0nn4OhXuZfxG4= 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=u4ygWjJ5; arc=fail smtp.client-ip=52.101.52.54 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="u4ygWjJ5" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=baP1EkHwWIebuTUASM0G8Ulpj5i9Ch5tY9BBPIjoZ4BtQpE0JqB9nCg0xa4Of5dhmYBO1L8KcOv8T4YWw72cdz1rsYZThF/IZlRsCN8pYidAqW7qmb9tdAdUCwc90Q4IKjhHtVvvX5yH9+fDmVKXZ13EC8WGblwJkZJmRbtgAciBbF30w4sZADsgNZu4t5bw866xnbw8dLqkoVKydBRAQLqqgSSg381jXN4IMY6q5EexOljHV6zeU0F/H8WFQe8Uxljy73I/ol0xp+ai+Iwly60TEhbTd+qSd3gpF5/A1877EpddtsJgMd2+4pWzIalD0+nOqVtrjXT6Ullz/Jl4wg== 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=L3PCm3xlSgHq7Z8NOQOqtzWp7Y+if1N7G1FlN5oEjoE=; b=a5tHgCHibK2LTrJ3KovBNBUDm9fqFd2lJ0gZgUYA0ppyabylOnkw0JEc2XnEtvlCWxp1VeQwsZXK91hJBbX0bvx4U7QoC5fYUwRy184qJLj2BTa1kMq5viNr6Qbl+zAAGl6Jc5Kql9N7e4mDzLmgHGBWFESRq8EZrfZcBTNryUPowT5lsAR1vDkbFUYppmIyAehjapPHM3BZ4jwmCuc5iptoB5afxX7n1cjE5ahF1NMOcMpiIgh7nePQ9wFEdFbqHYvmexkNH2uNyLx2bOUcxlPYwdKhVsPljdSMIWKcLQ+6K/3tqBenLRncJpSV2QCM+mEbvyyAzGDBQo8Ozvt39Q== 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=L3PCm3xlSgHq7Z8NOQOqtzWp7Y+if1N7G1FlN5oEjoE=; b=u4ygWjJ5pFGMm5/ciOB/dNEOZwbe3GEekxTDSTt6YtazEiID+oGFcoMTyxqWQwlAK8jh6KUydvNeNgFT/SJu4NjEMX0Jpab0uzoBfELTtRd5Qb1kTTRlImzFL2KnMlMps/M3bX9WrvZnC+U9Eh9wa+LFSYGlBGZTFHodmJe4IdQ= 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 SA1PR12MB9472.namprd12.prod.outlook.com (2603:10b6:806:45b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.113.18; Mon, 15 Jun 2026 21:05:35 +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.0113.015; Mon, 15 Jun 2026 21:05:35 +0000 Message-ID: <20bcde50-7e55-445a-9025-7e3a2ebe7d8a@amd.com> Date: Mon, 15 Jun 2026 16:05:32 -0500 User-Agent: Mozilla Thunderbird From: "Moger, Babu" Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre , Tony Luck , Ben Horgan , James Morse , Dave Martin , "Moger, Babu" , Drew Fustini , Fenghua Yu , Chen Yu Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: CH0PR03CA0219.namprd03.prod.outlook.com (2603:10b6:610:e7::14) 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_|SA1PR12MB9472:EE_ X-MS-Office365-Filtering-Correlation-Id: 03152c4e-b0d7-4a54-4d5e-08decb21d7d4 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|376014|7416014|23010399003|18002099003|22082099003|921020|11063799006|3023799007|6133799003|56012099006; X-Microsoft-Antispam-Message-Info: wwUpvneOiv41nW1yGxg+hJeLBIQHNndczMZtD9ufSHI6W79sPFKTNu/waHo/rIrYi4S5etMQWN/SnRJxKXpKvcFO6tcjWA3ro1Zj53w9RXVzcl+lSGl2RKhMO9K+V+UKb1LMMdL9B7JaktSoL8cUUKt5w2UYcJd1l6t/9F2pIH4PZB8/rw9Wq0akEsk1OaF3Hd9kTizw/4DeVWx0TT/Agk6RTPRMYZId0/oxP7s5N6uiZ8a5tvQ5cvlGu7cfRqqesbNntdiy3733aROcyCUpiyoJVBHJ/iQne1DYR36V1l+oqdMGfwwPUg1MbNhBjHkDGBP+MHRY+g3iIMHwktSynWTlQ1fZk2GTk+/NrjpQCT82Fhhs1SDtA/P8OtkI5JqlvkSNgNXbOO0NUKXxwxpsZNgkdFN+PU4wqQkDNTJlrhmXwdAf1d7kdTOvjnirzPoNf0vXW3RdKCPp2Ov3HlpQDAVozxjCa9UPHhj+Uncb6yKL2spdIfLfbLkOxozXXcR3L80bjeRXFKHRLiT62pm1zC0JDv0oZTPU4iHnJMvdH7Q7ECHLMH6Z4B56+Tj6RgNHv8UhEH0ibCTDB+6/pnItuRTaDpS+5zJdDFN9w+ZEOjfFiIozAEcxepq6wMMrlnAsJBsacZuJJ9yShSPRFesiuX0zTXf1y1Wv2VLm+1QoZiyoxh5t1EZo8AwKfwGGapuH 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)(1800799024)(366016)(376014)(7416014)(23010399003)(18002099003)(22082099003)(921020)(11063799006)(3023799007)(6133799003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YmhFR3N4M2t0UkRsRXA3dVZSZVZPNTJSeitaaEt2TVJuWFhncERoVnIxYVpG?= =?utf-8?B?OENmNjJwWVBqdmJUN1BsT2FoNFUvUHBNUUJteVZZcHlDcHRMZkJ1Y2EzczNZ?= =?utf-8?B?SG5qbjVja1hxcERCUGVxK3FPdmtBUHFzVEFDWS94WTVWc3R3OGZrSDFueFZs?= =?utf-8?B?SWhGemFGMVZkSWFCQnVvc3dMNkxOM2ZMZk1JODFRUUdaSy9nZHp4N3BhSmVi?= =?utf-8?B?c0ZmSnQ4QlJlNjRHNmV4dk9DL1o0RXVIUW9Mbkp4ZmFkNkgxWkpNUjdvYUg0?= =?utf-8?B?SXU0SzJyc2w0NzAvbVJQSXZORWpGc0VFQ3RsRHE1ZDJzUjdsRUhCNW1BU0tM?= =?utf-8?B?MjdTZmVrSWxlaGNoSkx0dEtVK0kwTnFkaTZteSt6UGpoT3lOb1NmdE5qMFdH?= =?utf-8?B?aVNTZ256UlBjS0pJbDlsb3V4ekhTaWJNbHN4M3NuMDhEdXFVUUJQbDRMMkFP?= =?utf-8?B?K1NxMnhIZTRicis1dTc0RU9yK1Y4UlMyY3JmUFlUVGFudWlGenU3bWtNTXdi?= =?utf-8?B?cFhXRnB0OVFlRlc0QTRGUzZ3SVk1WVBQMXpGZE1UeFl1Mk1NT1hCYWxzQnFU?= =?utf-8?B?SElNMldpZDN0empBZHRTZ2l2THo2cFhFbnVPQkNBS0tPa05mcWhrWUtHQnRZ?= =?utf-8?B?THREOWgyRUZyY1RBMXBnY20ySERldTliVEc2NHJvcWNON2pFZ3hHai9OV1dj?= =?utf-8?B?bFRvdUI4KzVhemIrSWxLSjh2ZXI1cm1Qb0xkVVhRY1pIazlBRnEzbHNsSjlW?= =?utf-8?B?aU9YVmtvQWppR3NjVlA0L09xY3NiRnpVL3pMZUl3T2UvK2ROMXpjOEdmMkt5?= =?utf-8?B?czAvOVFabE11b3pBTzYrbjR0c29lWFM0SmxjV2NuUTZPMkk5blRlNEhnS3l6?= =?utf-8?B?Wm1UOXRlcmcvbk0weUJqOENJcGxBTExvR29qa2lYZUtHNUEvYzVhTXI0VFhn?= =?utf-8?B?L1RoSy9KQU5kMTV5TjFrR1dqVmIzQUxrWWtDc20wbzV0bHQzRzZkWXZNancz?= =?utf-8?B?dXNYa09RZHhKejh4MlJwVml5YXVBMWdXaUo0KzN4Z3VxV2VNd0pYbUdma1Vy?= =?utf-8?B?TU9xeXVOV2MzWWhMYXU3RVorUzFNbFRkZjlMdlhsdDhrUnZRWVdtVURyNktj?= =?utf-8?B?eCsrVi92NmdhRUhZWGtMK2JISEdQOEpXajZ6VVB6ekNrNUl6bDRaVDZLZ2FZ?= =?utf-8?B?cndrR1dPM1Joc09SKys4dmlVc1lzVTlNTU02bHg4N0czWFV0U1RCa2NpRDZw?= =?utf-8?B?RlZ5MTdUTEZQN0Q3aTAyQUFrRU1Ea2Q3ZGo0bjZNNHVxZi9mRkpISVdaSEZF?= =?utf-8?B?enpOMVRpRzRCSFpiWGpneFp2MTk0WTlmUFVSVzRMZWV5c1o4eEg3N1dRV1hv?= =?utf-8?B?STlwY1VGcDZBaDB1ZnVZQS9EN1JaeTNXSnp3cS9sVVpOc1orUlBKK0JlbW1E?= =?utf-8?B?d3l3VXZiSmpRb1llL3BXRDMvQ2prc1FBd0M0YThVNHpJdWZQbnZheEl2MXkw?= =?utf-8?B?dTlNNmFmdlBSU1pFOWxuT0wzbS9WaVhDQlIxOHZQYkR2NGpEejBzbjZLR0Mx?= =?utf-8?B?SGRDR0haaythWVlsMUFwUGdvbGxKSnZmaGJNYkx6ZmdrWENtUU95Tjkrak13?= =?utf-8?B?dGpVTkEveFRwNEs5ZVc3dnJmWjhycGIvSjRlYnJ4SWtmK3JCQ2o0Z3dIUEhs?= =?utf-8?B?Sm51UXpuZkdYMjBxM01WQXU2ZEFWMVh2K0hhMjF6azFqT3ZUQkVOU25Ya1d3?= =?utf-8?B?Z2JLTTR0Qk5BMkF6c1luMWhXaGE1R2x6Q2FRTjErUlIvUmlGSmpHdHFIcHho?= =?utf-8?B?aTNqeml1WjBmQWQwMlcybzJYdVFVM21jR2c3dTJabHFYSC9NcDdoVUFISFhp?= =?utf-8?B?MjZpQi9IblllSFVqTTcxaXo4a2puM21YREZkTUZ3NXZYbFkycDVORlVkK3FF?= =?utf-8?B?dTdKR0lqSW02U2tLQjU2SkZTVGRXMlFaa3Vxdm1vMUFIK0YwR1E4WVhZNDVT?= =?utf-8?B?NGlnbkFCc1lRSE1HYkUrZVJna01OVU5aRkJ5UjZXT2VSZVozVWdkTnNKWWR0?= =?utf-8?B?QWsreHk1RDY1Snh6WEtKcklpTk9NdnRrUmo2UW5tNHE3TW9GeG1zc0tPQjlQ?= =?utf-8?B?d05VaWFxNlNudUlUbCtCWjJCUDBNQXNTbmhWT2g4S1d1a1MzWVJwc0dKYVZG?= =?utf-8?B?VzdkdldYUU9MQnhiOTlzQm5kY3BnbmJ0VitMeUV2ZS9oM09pMDM4VG00UjZ6?= =?utf-8?B?QW04WFRMaGpzL3VBSGI0QjRjeVBVY0psQnVPZGF5N3huWVBpa2lRUjBvZzFt?= =?utf-8?Q?qaPIezXMFwJFmeedr7?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03152c4e-b0d7-4a54-4d5e-08decb21d7d4 X-MS-Exchange-CrossTenant-AuthSource: BL1PR12MB5320.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2026 21:05:35.0289 (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: tK3ye8b22cA9b7XLvyAdxDR2MfNK79GExr2jZZj3+kYrVPOw5dvBjjZhEezm/l/J X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB9472 Hi Reinette, On 5/29/2026 1:06 PM, Reinette Chatre wrote: > 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 > Re-based GMBA patches[3] on top of this series. [3] https://lore.kernel.org/lkml/cover.1776980182.git.babu.moger@amd.com/ #sudo mount -t resctrl resctrl /sys/fs/resctrl #cat /sys/fs/resctrl/schemata SMBA_GBL:0=4096;1=4096 SMBA:0=8192;1=8192;2=8192;3=8192 MB_GBL:0=4096;1=4096 MB:0=8192;1=8192;2=8192;3=8192 L3:0=ffff;1=ffff;2=ffff;3=ffff Needed this change to get the schemata alignment correctly. Note: Renamed GMB to MB_GBL and GSMBA to SMBA_GBL. =========================================================== diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c index 979176b054e8..6123689e1250 100644 --- a/fs/resctrl/ctrlmondata.c +++ b/fs/resctrl/ctrlmondata.c @@ -512,17 +512,22 @@ static void show_doms(struct seq_file *s, struct rdt_resource_final *f, { struct rdt_resource *r = f->res; struct rdt_ctrl_domain *dom; + char res_name[16]; bool sep = false; u32 ctrl_val; /* Walking r->domains, ensure it can't race with cpuhp */ lockdep_assert_cpus_held(); - if (print_ctrl) - seq_printf(s, "%*s%s%s:", max_name_width, f->name, - resctrl_ctrl_is_default(ctrl) ? "" : "_", - resctrl_ctrl_is_default(ctrl) ? - "" : resctrl_ctrl_name_str(ctrl->name)); + if (print_ctrl) { + if (resctrl_ctrl_is_default(ctrl)) + snprintf(res_name, sizeof(res_name), "%s", f->name); + else + snprintf(res_name, sizeof(res_name), "%s_%s", + f->name, resctrl_ctrl_name_str(ctrl->name)); + seq_printf(s, "%*s:", max_name_width, res_name); + } + list_for_each_entry(dom, &ctrl->domains, hdr.list) { if (sep) seq_puts(s, ";"); ==================================================================== $ tree /sys/fs/resctrl/info/MB/ /sys/fs/resctrl/info/MB/ ├── bandwidth_gran ├── delay_linear ├── min_bandwidth ├── num_closids └── resource_schemata ├── MB │   ├── max │   ├── min │   ├── resolution │   ├── scale │   ├── scope │   ├── tolerance │   ├── type │   └── unit └── MB_GBL ├── max ├── min ├── resolution ├── scale ├── scope ├── tolerance ├── type └── unit 4 directories, 20 files $ tree /sys/fs/resctrl/info/SMBA/ /sys/fs/resctrl/info/SMBA/ ├── bandwidth_gran ├── delay_linear ├── min_bandwidth ├── num_closids └── resource_schemata ├── SMBA │   ├── max │   ├── min │   ├── resolution │   ├── scale │   ├── scope │   ├── tolerance │   ├── type │   └── unit └── SMBA_GBL ├── max ├── min ├── resolution ├── scale ├── scope ├── tolerance ├── type └── unit 4 directories, 20 files Does the info directory hierarchy look right? After going through the comments, it seems like it should cover most of the upcoming features. At least the Global MBA/SMBA stuff looks like it fits in well with the RFC. What is your expectation for the RFC going forward? Thanks Babu