From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 6A2D23DEAD7 for ; Wed, 22 Jul 2026 16:32:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.16 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784737933; cv=fail; b=L2sCLIYfpROVBLUD6bsqLNSmYSanLI8e2ij7w4VvfcJS73J2fpvDtEQX/D8OccdgrOAXCuyJcZ8mrInV47rEuYfTDnTLqGwTG7ywdjsiERIaq02jeO0qOs7pC9EnyJ0plP2maqy+RCpmAUCeQ4OmU8jWym2ug9GrbEs2w8zbgf8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784737933; c=relaxed/simple; bh=+NIZZxZ2Sj7NLdC+YTSVuxx56CFMygF2pVF6WORqYCA=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=mC1GBeY5vOR5c9rppNiDSM3IIVQqIuCKyMVdVRBmoEkm7rVnD6RqgI7yZglV56rxGirSgnBkp3164jqr95D/wwgqnO8D4UPqxPW9hrY5CtXoZGbCo0aZALTvrTQp2KXNbb+klYPqYfcxnJTGX/MDcw8WrNdHmxJ87pgsOS+jYcg= 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=SWe0OXCi; arc=fail smtp.client-ip=198.175.65.16 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="SWe0OXCi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784737932; x=1816273932; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=+NIZZxZ2Sj7NLdC+YTSVuxx56CFMygF2pVF6WORqYCA=; b=SWe0OXCiTtVk/qdnqiudjnV5TyiYATjFMfCNyguRYQsg1SZSN/6TS0MM WGEmXMphnRgTebk2AfHvey8vgvmXyEDWXs8JLdhcOyalW4CComY6+Xc5G gSXULBuVHfdGBNsi2M/PGAsdeiBAJT5OmfPabbukkbIxpXlocb3VBx2b/ 7uefKGDVCwzSuNAe/LhAB3TWGMLpYhVsIsjipMcf6thgGdPTkkfeGbuaE pymhbdtTY0/qm2QRr6o+55fljXwH+Jnr6k2y0fo+GAjt2/jSX8ybe4+Ro f+nnOcw8Etdw4xn3pCychp16bHppk/dNEqk5cOSl1jde9+fW2OpCKFBwG w==; X-CSE-ConnectionGUID: /UkvAioZSXqjjfgc9ZCpaA== X-CSE-MsgGUID: ggkaUQ3fSIGNuJvn0q5U+Q== X-IronPort-AV: E=McAfee;i="6800,10657,11854"; a="85573743" X-IronPort-AV: E=Sophos;i="6.25,178,1779174000"; d="scan'208";a="85573743" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2026 09:32:11 -0700 X-CSE-ConnectionGUID: Z349srzQR6yJMuzCkd8QDg== X-CSE-MsgGUID: E1A3aGIySGKveOC28OVRHA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,178,1779174000"; d="scan'208";a="261926646" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by orviesa004.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jul 2026 09:32:11 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Wed, 22 Jul 2026 09:32:10 -0700 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.43 via Frontend Transport; Wed, 22 Jul 2026 09:32:10 -0700 Received: from SN4PR2101CU001.outbound.protection.outlook.com (40.93.195.67) 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.43; Wed, 22 Jul 2026 09:32:10 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=srndp/5RDbpvX6+DeYC4K8ZrtsCqWsTtGIPtm4ZvPyEJ+t/kjoNfL8ncSJhOksw2wq4mKnxyte2L6HrAq0siRN4k5zfAkUQ8Zy20/jx1f/QZq1Z+hPzUZ4WELOEGntNUeViUAgaSmNf0p1w+ZX2EduH4ZP1gi+QudXu0zMWPHpQaZnDreQ9Fi+XUya/xN0SH9ZnJd9f8qqBg3kSXR7cbAK9eqs8VskVXV7IrExegtq5LISBgpRM4hJkoNCyhRBVcYRe9flxc6Zjt7uUNV7YpGS0rldqVZvJ9k2Ol6HFkxzRKpFONV6mRWWD7F4vnO3pozseLv8kX5VCWBhyRIL5oCg== 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=NSmDHRb+K+9dM6IMDrPFVXZCEJEK/2PFWBIb0lp8myk=; b=hdPa6r8boeklHjk9lEL39mjsZcTUFSMdlHI8NuLVMo5OXFKFdfgNR5mISeLTkFTreeDZ2FTuRSiBBtyYgHqGJsdtQONr9O++kWffCEOpbMsv00+m3R2rnFJdHnYRRJju8kAXBGAvvncUsh+1as8dqXokpernrmFHzfIfmgiDFPGIbUMVm3gF9FFEmXEZPWrdt+7v0WMZX6YOVvRNvLDBm6DV5DZ7AFgH13GOBIZCeGFNs/Gfr2+U/VD7h8ALaS+8bivQCKI//toYz71KGSfRBprWVPyP+Oqd5Y+6MoS0zX+xiOkU3//vbxHjPaGSxhGuTB7f4uMomWKQe/enxbByGw== 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 SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) by DS7PR11MB6293.namprd11.prod.outlook.com (2603:10b6:8:97::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.245.10; Wed, 22 Jul 2026 16:32:07 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%5]) with mapi id 15.21.0245.009; Wed, 22 Jul 2026 16:32:07 +0000 Message-ID: <18d0360b-5567-4c66-b4f0-9d6f25d983ec@intel.com> Date: Wed, 22 Jul 2026 09:32:04 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Ben Horgan , Fenghua Yu , "Tony Luck" , 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> <0fc6df54-26c7-43fa-948a-528cd94937f1@arm.com> <9049378c-699a-4155-b1e4-737a1d7265d5@intel.com> <57740b97-80ee-4632-bca3-dc43cd7776c2@arm.com> <44f26cd4-be79-476e-b002-7ccfb7705179@intel.com> <749bd904-523d-4e9d-8493-0e8cfd79949e@arm.com> <9db33feb-cf04-420c-a99a-e31e4b8e4954@arm.com> <8fd6caed-820f-457a-a1ef-a0a006fa52aa@intel.com> <4ef15dde-2fbb-4763-93b6-4333b02d6859@arm.com> <7b751c28-2f04-42b7-b957-af6447e7f824@intel.com> <34b95afb-8b60-4680-9ad1-90c5b24e8fb7@arm.com> <08f016bc-2ba6-439e-bb3e-20061166402c@intel.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW4PR04CA0313.namprd04.prod.outlook.com (2603:10b6:303:82::18) To SJ2PR11MB8370.namprd11.prod.outlook.com (2603:10b6:a03:540::20) 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: SJ2PR11MB8370:EE_|DS7PR11MB6293:EE_ X-MS-Office365-Filtering-Correlation-Id: d0ad8056-f11a-4549-35c8-08dee80ec514 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|366016|7416014|376014|13003099007|3023799007|56012099006|4143699003|11063799006|5023799004|10067099003|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: CvXpyZFkQmJNrcRCVeud45p1mBGCnUGZ4P871rozXkiOIeNTcB9oMoL3FzLhGpEwOdYKbXO3rYKwJGfQL19xO0JiYwj1mTkW3uPagRFk3MlL86V7ocloAm5y269D8D51uuDUxpAqgbkfOq2Nqk5LtljAqI/v+A71Q7/pUeokCd+4asd0sYk/xz461gg30vL8S5NU7YQDjczvd1/KY+Yehs51HcjcXT3D1sS/SYdFRaHdVXkwuLSRudp+wJ6wUbK66ELqCoDceS2vDVSP7abWx5z/8wnfrOXE4DIXvUrAXei22DJVYTsiEEcADHaa1mAbtljAPrpVIPB2mbrI/qSeajjcX4ofOqmp4HmrzoCnRY8s3egWVfHEgipe+IMZbYGuD9uVssLRX/MTOELx1OUorFZx1fe1AbRy+/56T4W41TcNcfO9sxfOqCU7AdAfkyyPXoJbOEty88cXrjMprUj8ejTuYQQieKgaGXLG7Mm0NUs7af/QblVrlKS2l4t1IaVOW248ilHZ1D01SwwM1hHLPyEJp1HFiUC4WqRLDe7aR3gk9mpEgIaYfKkstUpw6g+eKh4Il0rx18sNNJXeRwp0WNeEK21L1U8+Hrsc8ddLjxbl0Enwmh8WAeS63TN+zYGB X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR11MB8370.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(366016)(7416014)(376014)(13003099007)(3023799007)(56012099006)(4143699003)(11063799006)(5023799004)(10067099003)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cXpyTGRwbW1NbVIxWnViZHdvbmJPeVlROE1pZG9QSDJCNXZXQ3hVT0ZaRS9h?= =?utf-8?B?OXhlbGI1OG56T3djVXVjdFp1bjAxWTNla0dBekhDZDVMT2gxdkcvTkR2MEVP?= =?utf-8?B?d0xlemtTMzNHSTlLZGwwL1FOQ2NPQmlNNytXVEVZalFKNVZ2a2Rzb2tVYWRp?= =?utf-8?B?Tld5NS94T094RHhWZ28xVHFvNk5Ba2VjV25xQWRReXdHZzMwdDdINTFYV1pw?= =?utf-8?B?bW9vZHBYUXdhMWFrQ1lDYU1KS0pDeisraFc5RU10QVdSTjBqdzY3UHNlQkFy?= =?utf-8?B?aGZDT0JQMDMyb3pXUVJROG5nek9iZzBTRzBOSUlYeDBqQ0VIczU3OFJVQ1NX?= =?utf-8?B?VlBVeFh6SVFqdGg2d2FiaGlDNWEyTzFzMmt3SCt3VmVxODZhRGc2blowOHVV?= =?utf-8?B?REM2eXZnOE9HSjVnUVlKNFZzRHVMOUVkb1RXZE1BNkh5TUpjaUVKWG16RWVT?= =?utf-8?B?SkdPbE8yaW1CdEhibGRoVWNvS0FOdHlxMnpkOGYxZTRKMkNnSUIyTmlGWmdW?= =?utf-8?B?SmUzdWJtUmVHSEg0cnRjeDl2MG9QZ0tpVVVHNGIzaDl3a1JaY2F2QWpxVmRy?= =?utf-8?B?L1hrT1FRLzd0WE1WV3IxMGlaSS9JdEJ3elcyRFQvUERQcnhDQnNqUi9ZR3hw?= =?utf-8?B?Qy9ueW45S0hkbm84VkpFaUxYK1pIazdkZHlLM2gwRGlLQ3JrZTgzMks2eGtk?= =?utf-8?B?bUhjRlkwT1ExemVhLy8wUk5nU2kwL2loNFI4NFRhSk1rOVFiUXIyUGZRd0sr?= =?utf-8?B?OXAzdjBUMDhJL1EvWmxhUmhpYjdCYUdHcy9zZ09nWGFZY2FDdnNJNm1yR3I3?= =?utf-8?B?VlpvZTlwd2dYRy9yK2VuZ1NKV2l2cWRyU1BtaXRDbENZRmNCcHd2alNuMFFi?= =?utf-8?B?TFZKNzc1MlNaNnB2UUs5elhLR29IOFJFYjg2WkFJczhhY1RjM0RHaW5EbVla?= =?utf-8?B?OHBkUzZJUFZIS01MT0hQYUdPN2Z3NE9MclpPVHduYnZqSlJyN0xIdDNwQzJU?= =?utf-8?B?Mk81N084djVvdU1OZGVLK3Q3dFpFWEhhcnVnNEtDSEZqNEJVeEZNQkFodEQ4?= =?utf-8?B?YTZFMVlEL0FvNU9IMzErbDN5SDVIWWNXU1ZHaTBuN0t1MWx3RHBHNEdVT2lF?= =?utf-8?B?QitldE05RkVEVTNGVGdKVnpJbGZTSkNELzRobGxyOG9EeW1yMmQzL01BZ2dU?= =?utf-8?B?c0Jqdzdad2FVMG9BTHNFRHZTMjBzVHhoSTgyZnpQUXBocVo1TzIvZ21HYmE3?= =?utf-8?B?NU1uWUduQVJXNFpZMXR2MGdQMkRNNkZUcUlDbGRVaWIwKzNxbHJLNzJNZm9E?= =?utf-8?B?aGZ6bTNKMWNkcm0wdEU5TlV2allLekVjbnBHM1o2Wk15TWJEZ0FNaHB4TEZ4?= =?utf-8?B?dW1tUVplRHdWUU5ING96dUpNMFFZRUFUN2lxcklXQ3F4NUI1Rmw4ZndlQTJS?= =?utf-8?B?cjhsS0czanlWUXhNK2tsNi9GYlBKQVNLQ3FoNFpMOE95RUtDYno4KzlpeVFy?= =?utf-8?B?NlFVV3o2akZQTFMraWdwck01QkdoUGJEU2d6QWNqNWJSOWwwc2pRYVV5Z2N2?= =?utf-8?B?NkJvREtxdHpUU3FUeHNkVkxBY2lHWURVdnBvRE90ci9MVmJsWWV3NklZOHdm?= =?utf-8?B?NDNFL3A2L3N3d2JneTFqelQxMlc5YU1HT3JJT2YvZnM2RkQzOUFhL3FBYkF3?= =?utf-8?B?RVZ3SU84UmtVK2lUYWpvQ0g2azBhYkRrempjTEpHUG04ZC8wYVhwS0VOWHA5?= =?utf-8?B?MHVtNGt5TGVnRkMvUnV4NEc2MXRtTmsxcFZKNDZrRGVXcWZxbDE1bEYzaW1w?= =?utf-8?B?dVN1S0R6Vmc0YjZQcE5OZ0ZpQTFqYUxieTBKZXBXUXdwYmdSaGhQMDBZSDBX?= =?utf-8?B?dEdFa3Y4RGdNUlB4OWZJRXh5K0VqbWJ4dlBrYmFQWExZSWtlQ3RhKzhVUVd0?= =?utf-8?B?UjFoZUszdktWUWcwaVdRaUNXVGZYZ0JMLzNkSkdSdEFadldsdjltcWdHdWdt?= =?utf-8?B?cHFCS2cvSGNOb3F2cmRQa0NzK3Nuak9GclRRbE9lTVUwTE1vNDFyVEVRV3Iy?= =?utf-8?B?YmdpbVhxTmU3N2tsNVRyWUQrYWVJOUMzSmVsdzJWeDBtUmRwbWtRM1VDMUJh?= =?utf-8?B?NDc3bzJoKzdWZi9IclVJczd4MksrV2JQZEM2UFZWNE0wd0JVeUl1WnpjdW53?= =?utf-8?B?cnZONnF5bng1WXlaeVV3b2Z4OWNrVWtucU5UNldRWGY1dWluRktLdmdWZUJH?= =?utf-8?B?bitXclBEWTJtVHRnUlZER2RyRnVxSFh1cWZ0MEJBY1NFV0lTR3lxRUtMWkFs?= =?utf-8?B?RVl0TVhoZXk4MEwrVmVYRXI0Z0EvM1ROTGdZazJLN1hUNmNoSE5ERGQveVZK?= =?utf-8?Q?JcLH6q4a5CCGjNn0=3D?= X-Exchange-RoutingPolicyChecked: glh8PcrgTqXboJHTKKe3RPfY0vPWIp3+bKVZG3T969w7egU97E9cojF67lvF0y3VpPcsca8/NyIDHA74kpKKYMS3qegcrMQ0DbwY/Ks4QUcDIovC+Tt62jyvaDXJt+48FhRrcey1s4nkkeqHuaJBi+MA2aWdqlOEhjl21agzv9S5hKZLy7mqSto/itpZvgDJnavEXjzVP4S7yMMqfcN71y24raE3rIQZsS57K4svh6Pq6Io55tasTEI1mo55CXdAmg+BfYcoSyR3Iwp1WMdUTNyZKYsQEvltIwEKfDw8JMqoICwDYFnib5zZN1/6UCR5wqXBNjY78Levn76QOi+bjA== X-MS-Exchange-CrossTenant-Network-Message-Id: d0ad8056-f11a-4549-35c8-08dee80ec514 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2026 16:32:06.9035 (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: t17MSMz8Y5y0oHswBhpcDG17QDhlsjFFXZKI0krhcitOJ082Mo4PS+Yo1q0YMlY+HRf9OiJiJcRNPhQefz/dl3S9TEuEFzNCVRghYpIiipA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR11MB6293 X-OriginatorOrg: intel.com Hi Ben, On 7/22/26 3:03 AM, Ben Horgan wrote: > On 7/21/26 18:30, Reinette Chatre wrote: >> On 7/21/26 6:23 AM, Ben Horgan wrote: >>> On 7/20/26 23:54, Reinette Chatre wrote: ... >>> I don't think we should introduce more percent based controls and for new controls we can introduce >>> a new format to describe them. Perhaps just the positive integer with a resolution supplied in info/ >> >> No, we should not introduce more percentage based controls per se. With the new schema format a >> percentage based control is just a variant of a proportional scalar control. >> >>> as discussed previously. Although, I have been pondering on whether we can do a bit better. >>> >>> We could use hexadecimal point based format for controls which are a proportion of a resource and >>> have a resolution which is a power of 2. The advantage of this is that the meaning of the value is >>> independent of the granularity of the control (number of parts). >>> >>> 0 is represented as 0x0 >>> 1 as 0x1 >>> 1/2 as 0x0.8 >>> 7/256 as 0x0.07 >>> 1/2**28 0x0.00000001 >>> etc >>> >>> This maps well to the MPAM fixed-point fraction point format without having the weirdness of having >>> values forced to 1 or 0 not being really 0. These MPAM h/w oddities can be hidden just by using the >>> mbw_min mbw_max of a control. In MPAM this could be used in CMIN, CMAX, MB_MAX, MB_MIN and I would >>> hope this would be useful for other architectures too. I am preparing some RFC patches on top of >>> your PoC for consideration of this idea and to explore some of the proposals discussed relating to >>> generic schemata and how they land in practice from the MPAM side. >> >> I'm going to stand with Dave Martin [1] on this point with a preference to avoid floating point in >> resctrl input and output. > > Ok, but I'm not suggesting floating point. Dave's two objections to floating point were that it's > not exact and that it's hard to parse. For the first it is exact as it is using base 16 and for the > parsing it's essentially parsing a prefix, '0x0.', and then a hexadecimal value and shifting for > resolution. 0 and 1 will need to be considered as special cases. What I did wonder if it was too > weird a format for userspace. Anyhow, no point flogging a dead horse, let's just go with using a > number in a proportional schema along with the resolution as Dave summarized in [1] > > [1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/ ok. I do like how the scalar control from that proposal accommodates a variety of proportional and absolute hardware controls without forcing/requiring hardware controls to be a particular shape. > >> Could you please elaborate where values are forced to 1 or 0? The new schema format was intentionally >> created to *avoid* rounding errors (and parsing complexity). > > This a property of the MPAM fixed-point fraction point format in the hardware. It would need to be > hidden whatever resctrl schema format is used, percentage, scalar, fraction ... etc. Just a clarification, all three of the examples you mention (percentage, scalar, fraction) are currently expected to be supported by the single "scalar" control. (see later for comment on "need to be hidden") > For an MPAM MBW MAX control with a width of 4 bit the range of values in 0-0xF. In this set up the > resolution is 16 but there are only 15 possible values. For MBW MAX a 0 in hardware the minimum > value which becomes 1/16, ~6%. > See mpam_resctrl.c:mbw_max_to_percent() for how this is currently dealt with. > > For an MPAM MBW MIN control we shift the other way and so 0 is 0 but (with 4 bits) 0xF is 15/16 ~94%. > When the input resolution is a power of 2 these conversions between h/w value and schemata value can > be slightly simplified but there is still some ugly offset of 1. > > (The spec is a little less precise than this and uses weasel words like "Arm recommends..." but this > seems to be the sensible interpretation. See ARM IHI0099B.c "MPAM system component specification", > Section 9.3.) Thank you for the clarification. Sounds related to the weasel words in https://lore.kernel.org/lkml/20260709093111.367851-4-ben.horgan@arm.com/ that took us a while to settle on. You mention above that this would need to be hidden but from what I understand this is accommodated by the "tolerance" property of the "scalar" control? Per https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/: 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. >> [1] https://lore.kernel.org/lkml/aNFliMZTTUiXyZzd@e133380.arm.com/ >> >>>> I also understand MPAM to support more memory bandwidth controls ("MIN", "HARDMAX"/"HARDLIM", etc.). >>>> Do you envision them to exist within info/MB/resource_schemata/ as well as within >>>> info/MB_NODE/resource_schemata/? >>> >>> Yes, at least for MIN, see the info/ tree above. For HARDLIM, perhaps, but HARDLIM has the added >>> complications that it is a property of the MBW_MAX control and that it may be configurable for each >>> PARTID or a fixed property of the h/w. When HARDLIM is configurable the control name could be of the >>> form ___ where is HARDLIM and the full >>> name for the HARDLIM configuration on the MB_NODE resource is MB_NODE_MAX_HARDLIM. There can also be >>> an info//resource_schemata//lim file which has values, soft, hard, configurable. >> >> ack. HARDLIM sounds like it would be a new control type. Perhaps a "boolean" type for which new control >> files need to be decided on? Sounds like you are headed in this direction and already have one control file >> in mind for this new type. >> >> With this in mind the control could be built on top of what is being developed at the moment, possibly >> be presented to user space following Dave Martin's suggestion in >> https://lore.kernel.org/lkml/aO0Oazuxt54hQFbx@e133380.arm.com/: >> >> | MB_HARDMAX: 0=0, 1=1, 2=1, 3=0 [...] >> >> or >> >> | MB_HARDMAX: 0=off, 1=on, 2=on, 3=off [...] > > I'm happy with either of these format but have a slight preference for the second as on/off more > clearly indicates this is a boolean with only two choices. So far I am only aware of MPAM needing a boolean control which hints to me that MPAM can set direction here. Reinette