From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 8852A29D291 for ; Tue, 16 Dec 2025 22:26:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.9 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765923995; cv=fail; b=Q5nYRc6nFTvxjxKkOFlJntMKINkuXDQLjUgXf4qLjrmQ72PJT9/r8OgqHaeDAhECxI7M375iZADMm3xwWS9STZfD2on2w6uWh+oMGUroY8H7EminMFPrHETtkVi9nFd9ePkznr+SKJdn+iKqrDTqv5iDYWMfC3AKqvdhWxIdo4w= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765923995; c=relaxed/simple; bh=JZm9+44XipHhpJHuXVtIKJLv7RVoiv3VVQbOKz/TJ+U=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=GUgeZR99tl+O1uZ9oazBXm8WsS6B1iRFBxP4ZU9+t5kqdAyKYDaQ3Av6QSZciJW6X7eTMEAw5xGagF2Kxr+bLt2lFqu2RzK7Ik8NVEd0umq9Olm1FA+RIj5IGiV/5BXPis8bGypcXpsRxkQH4uqYr5EABl3ssOHIle8gQoFO9xY= 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=irKGD/dj; arc=fail smtp.client-ip=192.198.163.9 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="irKGD/dj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765923993; x=1797459993; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=JZm9+44XipHhpJHuXVtIKJLv7RVoiv3VVQbOKz/TJ+U=; b=irKGD/djMDa1i4VbeKgX1TyPs8O8H0hRCTXkvEK7FEBDIM3L33TG8Q9Q W42s0hnINiMYr9h1uGIxRRaUaaDlc0gqylqM9FGZdpzEIaAWCdKegfJbP AbeeUeJ6GFXxkL1EuN5cL/fMUO2PcK/R4mLSlTuKqgVy7bWqfR3leHnTK SmVrLnckWDHCSVhto3San5ca8w8f6ppEW/da8BI2UWoDCPbJxe4UvE8mH Mf7POwwTbCT4AEOu/vowoj2FEAHLHlUi3DfFYWtLDgcvW5fjpsw1PXIoo ueW1/+qraHL1bJORIleLP+4v6qbYbhSxOLh0ldoQLLC0lq4vjKXzEuZRT w==; X-CSE-ConnectionGUID: GMuGqCqASdqqcmD3LVE94A== X-CSE-MsgGUID: efvbEk9uTp2C37xcSoLHjA== X-IronPort-AV: E=McAfee;i="6800,10657,11644"; a="78565265" X-IronPort-AV: E=Sophos;i="6.21,154,1763452800"; d="scan'208";a="78565265" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 14:26:32 -0800 X-CSE-ConnectionGUID: jMfjPZl1QOOcxsKhoHzbeQ== X-CSE-MsgGUID: HALMJ2N/Q8mZTTq2NCtSjw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,154,1763452800"; d="scan'208";a="198026319" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa006.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Dec 2025 14:26:32 -0800 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Tue, 16 Dec 2025 14:26:31 -0800 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX903.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29 via Frontend Transport; Tue, 16 Dec 2025 14:26:31 -0800 Received: from CY3PR05CU001.outbound.protection.outlook.com (40.93.201.53) by edgegateway.intel.com (134.134.137.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.29; Tue, 16 Dec 2025 14:26:31 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gAnUIkb2TJKZ1dXQCIx4jvNu5u1PX7to/K0lFimdCfJsNFEf7PoM/06rGKUaHMhFIjs138InGoDLhQX61QD0VoqVHF/kwy9KXGVIWHWfLE2tOEicgqtLk6mncwK+nzyFM0XX8OXHtHY0JQxF5KAL3svPX36UBn42Rrn804yxCA+9N8Lb4Z1/JHE8yGOug5NFF+wxguhZaxQH6FCUYOcke8I17CcofZbRrecRDwAtKovsH5W9ScxvkXiSpnpLO4f4cfeAY/LiMkfIBrCr1MlR39Y7AmAtKevKWe8Ko9SmGdR2Y9y3OWjhfFfh5V1M4k7N/JqSceGyyH4Iz7UBauvGLA== 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=mhFJsbgcMeQdRsgpYv1/jTZenfEQQF2E6gVL3sNzqVU=; b=aNeRJ+Vn6k8NK/7tLHNrRJLH0nHj1tJdlkBpHlJ2MohEwoAEfmVuyZOFlTuDxQK1jPsRupvq8Uogda7vjVKsCxCo5zDgTLW1j+9R4RHsIpJkdOyjdl1dhXXMSYofZgd/4lOUd4TsxwJP69SNL548ZPsuSFm/8bOpTS1/ptd+se9vgiv3ieoCyDROQMTkGXHcCM15/0ng1iz7xks0Oo7BX9aEYYkDv4NLCiqe5jyKqbcc5AcMtUCGGZRSx9UbJ5DafQorUUofYJLt4cOHmXmOaIowZbtNpYO8lS18DUcROBomCHOe2UQHJ+klAtyN1vUqN2oMzSLTLCQlXlO0bs2eTA== 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 SJ2PR11MB7573.namprd11.prod.outlook.com (2603:10b6:a03:4d2::10) by LV1PR11MB8841.namprd11.prod.outlook.com (2603:10b6:408:2b2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9412.13; Tue, 16 Dec 2025 22:26:28 +0000 Received: from SJ2PR11MB7573.namprd11.prod.outlook.com ([fe80::61a:aa57:1d81:a9cf]) by SJ2PR11MB7573.namprd11.prod.outlook.com ([fe80::61a:aa57:1d81:a9cf%3]) with mapi id 15.20.9434.001; Tue, 16 Dec 2025 22:26:27 +0000 Message-ID: Date: Tue, 16 Dec 2025 14:26:23 -0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] fs/resctrl: Generic schema description To: Dave Martin , , "Babu Moger" , Fenghua Yu , CC: Tony Luck , James Morse , "Chen, Yu C" , Thomas Gleixner , "Ingo Molnar" , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , "Jonathan Corbet" , References: From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN7PR04CA0097.namprd04.prod.outlook.com (2603:10b6:806:122::12) To SJ2PR11MB7573.namprd11.prod.outlook.com (2603:10b6:a03:4d2::10) 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: SJ2PR11MB7573:EE_|LV1PR11MB8841:EE_ X-MS-Office365-Filtering-Correlation-Id: 97f0b7cd-6ccb-459d-3c38-08de3cf2270a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014; X-Microsoft-Antispam-Message-Info: =?utf-8?B?b3dWclQzaS9mT1d6S24rMlZGWm9sN0s0OGlvcUpvTVNzRHFwS2doTDVzNGR1?= =?utf-8?B?N0tMVVJXTzhqWXJxRDFVNWdzM24xcWthYVA4b29OcVAzd1EzaHZCNUd6M2FK?= =?utf-8?B?ODFsNmNaMXI3VWQ2eExmNmVqZE9TUE5MU1Z1RGx0RTR5K3daWExoZmEyNkFS?= =?utf-8?B?clMyTHJHekx3VXdNVzB1YzcrMVBiamhVditCbGl4M0l4bGdvVXNaaXZsTlUr?= =?utf-8?B?eDRjUU84RFMrNksrd05vTkRWZHI5TSsrTWxVTVV1Smx3dGdIcUVYdnNUaG01?= =?utf-8?B?Zk9NU3J2cDRmTGNwWFI5NXFDNmJxT1JCRG9IUFRpWTVydmUrQ2dOR1RYaXVQ?= =?utf-8?B?NGF2Q29nOWNESzV0U1gyNTRyN3QwQmZaaTlxbmxNWWdUblhLdmVaemQzRU5W?= =?utf-8?B?QXJLZThhek9TMnRVVmFwcnRSOXRRT1JMNU9CSTlRRmVNd0hhOUVKaUJzaTBR?= =?utf-8?B?dm5RellVV1BXUzhZcU0rMTRGc0R3aUxGMnpXL2ZMcTdRL2dkMTNrRy8xdFJp?= =?utf-8?B?OXBKSmoxd1NVYnA0ck9OSDdaTVlZc0l2VzdPUjR3UW9EZGFxeHVjQ0VnTlRw?= =?utf-8?B?MG9qWHhCS0xpQUEveHhGY0RCNkNDNjkxbUJVZ0dvMGdsTXpBM0IwOFV4NlBq?= =?utf-8?B?Y2lNejJ4bHRQZzZET2tINEZHZDMrY0lWanRTZ210QXBlTEdwSklSejR0QWNp?= =?utf-8?B?VzlRNzUrVUlXT1lSMXVBb2l6WmZOdno0VG4rV0ZIZ1JzKy9pWjFZVTZCSE4y?= =?utf-8?B?SmdiVEFidG9HdjYvMk1xeE5jUklpQUVydG1OWHpYOFVOSzlzam9MWmJCcVBh?= =?utf-8?B?R1Q1QjJNdmV3NGZJMXF4cGFyY0xlZGNUYitsdmpiZTc4Yk53K0w2OEo4MXNC?= =?utf-8?B?YlhSaitESTFCc01CNEpqbTArREJXdmI4M2JXMXVKRTA0bFNyb2FKUWlpSnpK?= =?utf-8?B?aGloU1RyeXdGT3ZPZW91OFRxZkMzb1NnY3JkY1hmQnhPM0M2MkJ1V29EdDRN?= =?utf-8?B?Q2MyYlRtYzdVNFNoVUtldEJqcUxjUHpOa3lGR0dCRU5zaUs5VFdYQ3F0K3l4?= =?utf-8?B?azY2ZDVxSExpUVFnTHVkL2V4aEk4SFB4SStGS3hFcnlzaHFYRG16NkIrQ0U3?= =?utf-8?B?T1NlTWVXN21SbFBpSml4bXRVNGdjUDdtYWlEY3hIazF0ZG1nbmFXbElXOStK?= =?utf-8?B?NkZWRHdVQ2Q5N1BNTzZEbG9SVktEZGVHVnU5V01IZ3hDdVZtTXVlWmhOc3Bk?= =?utf-8?B?Q2ZQR3l4QkZvZ1hiOERIKzNUUDlCYUYzWVJjWGcxQ3N4R3Zqc25JejdHL2hy?= =?utf-8?B?V0N0T0tMQTVyVUpiQ0VtbkxLU3NZNCticWd2OVo0UDVMU29jdzZpUU5XaWhE?= =?utf-8?B?Rnh1TUpNaWNQS1h1TDhpNVN1ZU9TMzBpUzM3K0JsWmphK0JnanpxanIwM1BN?= =?utf-8?B?RjVPUmhTd2pJaWZxbWp4TzJDMzhOQ2hQZDFsVjV2N21rZlE0V09qTVg5Nm5k?= =?utf-8?B?Q1BxTWplR2tTdXIvclF3NkZxRzlxVStxclJCalQxVTFQdnd3TWFoTGIxY25Y?= =?utf-8?B?TC9haHN6aFFCZkNsMVc2MUhIMms3SDY0Um9mWDNKTCtjdFFGRHBCYjNHWW1n?= =?utf-8?B?a2R2OW12YW9KckdCVTFZaXhmL0Rhd0JnWTJTSVBHejZZbEJsVnF3Z2JFallO?= =?utf-8?B?ekJHRUorQUxuUWtKOVhUN3UrVkw2VkQ3aHI5b3lHdEdZK3BScGhiQk81YnlT?= =?utf-8?B?dG81VWtubUw5eDlEMzZDbEtaTXR5RWVNOVZpWk1QWHhZY2dQeDNxeDFmSXkw?= =?utf-8?B?Y1BqNkw0MEJKVG9jUFZFck80WHd5RTNvVzZWOWJ0UE9aa3diUlJ4aVBzdFpX?= =?utf-8?B?L3RuT0xSTjZxZ05Xb2NYQmZOWVA4bGJ3ZU9mZkR4SElqb0VQbFNDN0tvVUZB?= =?utf-8?Q?7RqR/LOnJVU=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB7573.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vm80SEp1R0NFbnRyd1g1UExyWFZna0YxQ3FyelpSZGNuRGpyUFdZZzc3WCtO?= =?utf-8?B?bFk5azFWQ0lPZ3dNcjZPa05mUG12ZjVsdmtLek5MVk1IbW1kMHdFOUNIVHZq?= =?utf-8?B?TnBhb3ZCQk84ZVoyV0hsaWZuMDZXMUl1UUhxY1EwSkVXNGZ5MTRBVnVpVWpx?= =?utf-8?B?bi8zaDR5NkJocHBPQXJ6b3dmNlh6ajFCenk0TWJ0akxyVytoRk9ySTBQck1F?= =?utf-8?B?MlViR0d0MkpLZE1aUXZPUHJYLzFzSTlzRG9WbUlpcDM3OGw4aVhqOHBXWGtM?= =?utf-8?B?R3NmQnRRNUl2MEhsWU0rdW8yVVk0bElyamp6b01yRGJ5TmdTa3I4Z3Z6VDNQ?= =?utf-8?B?YW9jdG93dXBWdTYvYVVSS2h4dURVUXBGWitabjZ1MzFQc051bTIzR3NiclZv?= =?utf-8?B?NXNFSmplcndnWmxlb1dtbnFpV3Mza2pTdC90K0JnRGpPL01BUVBUNnVyWmMv?= =?utf-8?B?d2lyUkhZWTBQem1la3BhdjhzMmRGUHRzVUN4cGQ3QzBXS2UyUSs3RCt2bnVw?= =?utf-8?B?TGdSVmpleGNZUEk1U0VwODVFeTRXUEFVeDVqNHhMN0laTzFMRy9LRHBPMzYz?= =?utf-8?B?R1p3b1pRUEJKUk9sWWVuZ2tGYUsxVFdiOFYyZWpxRk9jZEkxSXUwTlNHdjNu?= =?utf-8?B?eEtsYVFFbXJVOWlkY3doOXF3RmU2VFp0UVZYS0JpbHVVOUI1N3d2NWh4Q0FW?= =?utf-8?B?WGJPUGFheUtyM3IwcE9xajlndTZJWXhlamYxaGJjYkNqRHkxL1BXaFl5VFNS?= =?utf-8?B?cE5sUlZhakJ4aEYrcyt1ejZSL0RaczlZTmhUQWpiZ0swS3dyN2s4OUVzRm5t?= =?utf-8?B?SGFRazJwaGR5VndLZnprMmcwQXU1Z3hZWEhhNzNaVUN2SVV1TUVrdktaWWli?= =?utf-8?B?QSsrY3k5SWQxU2c5TkRVYTZiN2pFTDA1MjlCS2FSYk9jSVEwaHE4K1FZdFhV?= =?utf-8?B?dnBZWmRETnNNT0tLdUhhYmNYM1hDaHNmOEgydTZsV2J6WG5Hd0RZeHZqenk3?= =?utf-8?B?UmZuZUVrbFhNK1BsaEV0ejUrOEJUc3RqdFVBYlVSelE5d2pKbjVyYUpjQmJT?= =?utf-8?B?eGtYOGtvNklWVDg0dFVRckw1RU1RNnZQWDRzZHhLTWJmUE5ISFVkbjF0RW9m?= =?utf-8?B?dEhpLzdicCtONXpJazQvQzVIeVh3QmF0K293RkZVbHVwYW5sazFPSnhCeG4w?= =?utf-8?B?ejZSZ2oyRG02cDRwajE5N1ZLZzBqclVwNnk1RTgvS3JSU1FjQzJRNlptK2ZB?= =?utf-8?B?dWgwNFR2VTR4cHhEZVViNm9qcTNQdXRRZWZWWUVHTFlhaUhkWk9iUVdIR1pU?= =?utf-8?B?TkV0RGpIYVBPR1BSZjhqOGx4VWxISjJLajluQlU2QzFLRmtCZVRXam92cDRk?= =?utf-8?B?Yjlndk5PYngwWFd5RzlOeUhCNUFHMXB5b3BKUllCczJoYUlkbHdDQTNsMTMx?= =?utf-8?B?REF2TEQ4UEpkUkE5eWN3aEV4akZZMmhidjIvRmdVOThrT29NV3l3M3kzVFNk?= =?utf-8?B?V05pV2ZJU0FHY3pNMDY0YU9rODkwWEhwekUvTmo2TUZHVFV3TjVpZCsva2xN?= =?utf-8?B?MDVCZUowSFRzR1RoeUJDNEhsc0ZkQ1QvcEVRSnl5MEUvYzJaME5qVCs3WEhE?= =?utf-8?B?K3VYREMwcENPMG1LR2FRN2doTHZCbUpGcll2Q3JkQ29kaCtra3NqTnRaNVVy?= =?utf-8?B?TFhWZGJOVzVhZFYwK05KMEhrb2NpWTIvVkpEb3l2dGkxUzVCZ3dnS2VnMGJ2?= =?utf-8?B?TVYxcDZLVnMxOGxUbUNiR21PQjFRUVFtTk1ZYTZhL1lFWncyWG1oNG9jbEc4?= =?utf-8?B?clk3djk3VTFOM3ppWENubTJLZ1d1RlpRM2w3TGdTMmlubWhwb2gxSkdGMHBp?= =?utf-8?B?WE5RWXBDbzliNXBKUHN6Z0pDSzRDa3BjWXk0b1l2eUZIS2ZUdUVRNkVHOHpW?= =?utf-8?B?eHd3eWpOYXBncWdyV0Z0RXIwdXE3TVYvYk1IL2owWkdoaWxORzhFSWxOT3N0?= =?utf-8?B?VlBrM2x2QndoWHk3dGIvaW5FL3dmSkFZZFJmUGlWQ1hiOG8wWHBzK09QVXRP?= =?utf-8?B?T1FSa1YrM0FBMGNDTWxRVGpLcnZadk1jeG05N3d2K2dVckQ5enJCbDFtazdE?= =?utf-8?B?azRoSjhva0xuVjNMWUdSVFRJbzViZm1WenVqVmFzaTAxMWNZNWhwdjZzNncw?= =?utf-8?B?Snc9PQ==?= X-MS-Exchange-CrossTenant-Network-Message-Id: 97f0b7cd-6ccb-459d-3c38-08de3cf2270a X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Dec 2025 22:26:26.9944 (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: BTTiSA9Ia1oX2yoqukB62ZywG07Mi1//lwKIBQGwtRnerym9OSoYopkAZnk4qbn3M9oPLVoMPbjLAGy9fS+cGto9OBntX+D2Fl+/3QQiH8s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV1PR11MB8841 X-OriginatorOrg: intel.com Hi Babu and Fenghua, Could you please consider how the new AMD and MPAM features [2] may benefit from the new interfaces proposed here? More below ... On 10/24/25 4:12 AM, Dave Martin wrote: > Hi all, > > Going forward, a single resctrl resource (such as memory bandwidth) is > likely to require multiple schemata, either because we want to add new > schemata that provide finer control, or because the hardware has > multiple controls, covering different aspects of resource allocation. > > The fit between MPAM's memory bandwidth controls and the resctrl MB > schema is already awkward, and later Intel RDT features such as Region > Aware Memory Bandwidth Allocation are already pushing past what the MB > schema can describe. Both of these can involve multiple control > values and finer resolution than the 100 steps offered by the current > "MB" schema. > > The previous discussion went off in a few different directions [1], so > I want to focus back onto defining an extended schema description that > aims to cover the use cases that we know about or anticipate today, and > allows for future extension as needed. > > (A separate discussion is needed on how new schemata interact with > previously-defined schemata (such as the MB percentage schema). > suggest we pause that discussion for now, in the interests of getting > the schema description nailed down.) > > > Following on from the previous mail thread, I've tried to refine and > flesh out the proposal for schema descriptions a bit, as follows. > > Proposal: > > * Split resource names and schema names in resctrlfs. > > Resources will be named for the unique, existing schema for each > resource. > > The existing schema will keep its name (the same as the resource > name), and new schemata defined for a resource will include that > name as a prefix (at least, by default). > > So, for example, we will have an MB resource with a schema called > MB (the schema that we have already). But we may go on to define > additional schemata for the MB resource, with names such MB_MAX, > etc. > > * Stop adding new schema description information in the top-level > info// directory in resctrlfs. > > For backwards compatibilty, we can keep the existing property > files under the resource info directory to describe the previously > defined resource, but we seem to need something richer going > forward. > > * Add a hierarchy to list all the schemata for each resource, along > with their properties. So far, the proposal looks like this, > taking the MB resource as an example: > > info/ > └─ MB/ > └─ resource_schemata/ > ├─ MB/ > ├─ MB_MIN/ > ├─ MB_MAX/ > ┆ > > Here, MB, MB_MIN and MB_MAX are all schemata for the "MB" resource. > In this proposal, what these just dummy schema names for > illustration purposes. The important thing is that they all > control aspects of the "MB" resource, and that there can be more > than one of them. > > It may be appropriate to have a nested hierarchy, where some > schemata are presented as children of other schemata if they > affect the same hardware controls. For now, let's put this issue > on one side, and consider what properties should be advertsed for > each schema. > > * Current properties that I think we might want are: > > info/ > └─ SOME_RESOURCE/ > └─ resource_schemata/ > ├─ SOME_SCHEMA/ > ┆ ├─ type > ├─ min > ├─ max > ├─ tolerance > ├─ resolution > ├─ scale > └─ unit > > (I've tweaked the properties a bit since previous postings. > "type" replaces "map"; "scale" is now the unit multiplier; > "resolution" is now a scaling divisor -- details below.) > > I assume that we expose the properties in individual files, but we > could also combine them into a single description file per schema, > per resource or (possibly) a single global file. > (I don't have a strong view on the best option.) > > > Either way, the following set of properties may be a reasonable > place to start: > > > type: the schema type, followed by optional flag specifiers: > > - "scalar": a single-valued numeric control > > A mandatory flag indicates how the control value written to > the schemata file is converted to an amount of resource for > hardware regulation. > > The flag "linear" indicates a linear mapping. > > In this case, the amount of resource E that is actually > allocated is derived from the control value C written to the > schemata file as follows: > > E = C * scale * unit / resolution > > Other flags values could be defined later, if we encounter > hardware with non-linear controls. > > - "bitmap": a bitmap control > > The optional flag "sparse" is present if the control accepts > sparse bitmaps. > > In this case, E = bitmap_weight(C) * scale * unit / resolution. > > As before, each bit controls access to a specific chunk of > resource in the hardware, such as a group of cache lines. All > chunks are equally sized. > > (Different CTRL_MON groups may still contend within the > allocation E, when they have bits in common between their > bitmaps.) > > min: > > - For a scalar schema, the minimum value that can be written to > the control when writing the schemata file. > > - For a bitmap schema, a bitmap of the minimum weight that the > schema accepts: if an empty bitmap is accepted, this can be 0. > Otherwise, if bitmaps with a single bit set are acceptable, > this can just have the lowest-order bit set. > > Most commonly, the value will probably be "1". > > For bitmap schemata, we might report this in hex. In the > interest of generic parsing, we could include a "0x" prefix if > so. > > max: > > - For a scalar schema, the maximum value that can be written to > the control when writing the schemata file. > > - For a bitmap schema, the mask with all bits set. > > Possibly reported in hex for bitmap schemata (as for "min"). > > tolerance: > > (See below for discussion on this.) > > - "0": the control is exact > > - "1": the effective control value is within ±1 of the control > value written to the schemata file. (Similary, positive "n" -> > ±n.) > > A negative value could be used to indicate that the tolerance > is unknown. (Possibly we could also just omit the property, > though it seems better to warn userspace explicitly if we > don't know.) > > Tests might make use of this parameter in order to determine > how picky to be about exact measurement results. > > resolution: > > - For a proportional scalar schema: the number of divisions that > the whole resource is divided into. (See below for > "proportional scalar schema.) > > Typically, this will be the same as the "max" value. > > - For an absolute scalar schema: the divisor applied to the > control value. > > - For a bitmap schema: the size of the bitmap in bits. > > scale: > > - For a scalar schema: the scale-up multiplier applied to > "unit". > > - For a bitmap schema: probably "1". > > unit: > > - The base unit of the quantity measured by the control value. > > The special unit "all" denotes a proportional schema. In this > case, the resource is a finite, physical thing such as a cache > or maxed-out data throughput of a memory controller. The > entire physical resource is available for allocation, and the > control value indicates what proportion of it is allocated. > > Bitmap schemata will probably all be proportional and use the > unit "all". (This applies to cache bitmaps, at least.) > > Absolute schemata will require specification of the base unit > here, say, "MBps". The "scale" parameter can be used to avoid > proliferation of unit strings: > > For example, {scale=1000, unit="MBps"} would be equivalent to > {scale=1, unit="GBps"}. > > > Note on the "tolerance" parameter: > > This is a new addition. On the MPAM side, the hardware has a choice > about how to interpret the control value in some edge-case situations. > We may not reasonably be able to probe for this, so it may be useful > to warn software that there is an uncertainty margin. > > We might also be able to use the "tolerance" parameter to accommodate > the rounding behaviour of the existing "MB" schema (otherwise, we > might want a special "type" for this schema, if it doesn't comply > closely enough). > > > If we want to deploy resctrl under virtualisation, resctrl on the host > could dynamically affect the actual amount of resource that is > available for allocation inside a VM. > > Whether or not we ever want to do that, it might be useful to have a > way to warn software that the effective control values hitting the > hardware may not be entirely predictable. > > Thoughts? > > Cheers > ---Dave One thing I was pondering is that resctrl currently uses L3 interchangeably as a scope and a resource but if instead that is separated then it should be easier to support interactions with resource at a different scope. I am concerned that, for example, support for Global Memory Bandwidth Allocation (GMBA) is planned to be done with a new resource. resctrl already has a "memory bandwidth allocation" resource and introducing a new resource to essentially manage the same resource, but at a different scope, sounds like a risk of fragmentation and duplication to me. What if the "resource control" instead gains a new property, for example, "scope" that essentially communicates to user space what a domain ID in the schemata file means. It is not clear to me what a "domain ID" of GMBA means so I will use the MPAM CPU-less MBM as example that I expect will build on SMBA that supports CXL.mem. Consider, an interface like below: info └── SMBA └── resource_schemata ├── SMBA │   ├── max │   ├── min │   ├── resolution │   ├── scale │   ├── scope <== contains "L3" │   ├── tolerance │   ├── type │   └── unit └── SMBA_NODE ├── max ├── min ├── resolution ├── scale ├── scope <== contains "NODE" ├── tolerance ├── type └── unit With an interface like above there is a single resource and allocating it at a different scope is just another control. This correlates to how other parts of resctrl is managed. For example, it can become explicit that the monitor groups' mon_data directory contains sub-directories organized by scope. For example: mon_data ├── mon_L3_00 <== monitoring data at scope L3 │   ├── llc_occupancy │   ├── mbm_local_bytes │   └── mbm_total_bytes ├── mon_L3_01 <== monitoring data at scope L3 │ ├── llc_occupancy │ ├── mbm_local_bytes │ └── mbm_total_bytes ├── mon_NODE_00 <== monitoring data at scope NODE │ └── mbm_total_bytes └── mon_NODE_01 <== monitoring data at scope NODE └── mbm_total_bytes What do you think? Reinette > [1] Re: [PATCH] fs/resctrl,x86/resctrl: Factor mba rounding to be per-arch > https://lore.kernel.org/lkml/aNFliMZTTUiXyZzd@e133380.arm.com/ [2] https://lpc.events/event/19/contributions/2093/attachments/1958/4172/resctrl%20Microconference%20LPC%202025%20Tokyo.pdf