From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 71C792E7F39 for ; Thu, 16 Jul 2026 16:04:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.17 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784217871; cv=fail; b=mGp5aHwU4U5ag66k/GSmk4FKLzu5fVyU+t69Js07jWcHXkuUSYI78qfbgH9pBOw0HQ/UpVxmV/kZmcAsBWZcoZVz7oeALUXxyOqQrUk/aB+RBIXwlb1i+OzQ37xK0sdh0dn0aZSpYw3tZrpTSAC9JdkmZeO5uwyiKUHmTMvwaQc= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784217871; c=relaxed/simple; bh=xVz/HjvCt4dGU8BdNdtuI3xHFuMlvfLXbzbg0pUukcE=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=VBeIc0bMBsNLE3Cr/KCQ8qiL7we2ZPsu+4S7SA75ZRUKwGw1604HZ3zkijN1Uonlo7uAB0edKPowIU04YF3hPGdR89c5p2qjQ4cNTMDBAx06gHztB0V8Nh99k6aOHyVoVPHbzrjIwusNBM9cJFfIkO+06+v5d+DZevupXy808eg= 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=N7K4fKjZ; arc=fail smtp.client-ip=198.175.65.17 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="N7K4fKjZ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784217869; x=1815753869; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=xVz/HjvCt4dGU8BdNdtuI3xHFuMlvfLXbzbg0pUukcE=; b=N7K4fKjZnnrlPNm33muPycdxahm6YXxpJzPO9SVA2goR2x4w9zgPU76e Hj2SvndvcCGB3K0VeljmEd7WRKAIBEdm/YLzTBSvQro+qYT3IZV4o6Y0H +KTvCAsAhQb3qgWA0jw8d+9JSOprx3rQlM2RSKGver/GCmBS6Rdsk1Of3 PFqjweN1wY3baTrr+1DrMdQqZvo7UuN25dhmj8f7NHVt2VwIQwME+bJZ8 zI5Dm2ger5VOyBsn94QBDHNgnXtZz7/qaWHGLVfwnVlrRM2U0dRnzr7aw e3t9Qzlq5PPH+iEeqVnc537+SEr9Z311kZWABsy0qEeuESchHVp4zY353 A==; X-CSE-ConnectionGUID: /tUgaZhBRkayRXXytr7hDg== X-CSE-MsgGUID: VeMqtYrtRc2wMIM+RNRjOA== X-IronPort-AV: E=McAfee;i="6800,10657,11848"; a="84908079" X-IronPort-AV: E=Sophos;i="6.25,167,1779174000"; d="scan'208";a="84908079" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2026 09:04:28 -0700 X-CSE-ConnectionGUID: Z22EGPKlQHm3Qao5ck6/qw== X-CSE-MsgGUID: 6QKOYeYTT5+YmEqRAhldNA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,167,1779174000"; d="scan'208";a="260349461" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa004.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jul 2026 09:04:27 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Thu, 16 Jul 2026 09:04:26 -0700 Received: from fmsedg903.ED.cps.intel.com (10.1.192.145) by FMSMSX903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43 via Frontend Transport; Thu, 16 Jul 2026 09:04:26 -0700 Received: from CH5PR02CU005.outbound.protection.outlook.com (40.107.200.71) by edgegateway.intel.com (192.55.55.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Thu, 16 Jul 2026 09:04:25 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lrcbrL1IDBcQGbCnWNtI1nypkN0gNqRZAE5cfbslmyJC0a91uWtyzY7fIIWJMrTS/mRobz9LFc2wJsxQbDxCvSaParw0cQ1z1u++sptHz2RIXK3e+HUlnvddhOKwTzdmsJpUCnLXBMAC7AohjtLM95DUxeXk5ipiudllcZf6V6Rt1TYqztm/gWcCo4h3kUH3I1PMDjYaqeFUzOtbacMVIFF6hYzqU5840WjNBuKyxszW01cmhAlVmBg86PSMhLNV36phnC4PW22P1cSFntx0qlOHbAsG59n6DZP5TCMU6ICef3VJX/06MsV/HSMgfO3VvQrxYuJAqm5Bb3iPyCMUxQ== 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=/dVaboHMauyewrwp33IeOIMZjpdSkVxf1C7CyZstx+s=; b=hsj4hlyFNhxGMo4vjT85SUKFqrt1KzCmGsoZEfyCTzAV8EKmFt0+A6hObwEPyIO1MWQ7FFhRqJhodU2ivevFzw+zVQqOJKP5iwCFSH6QX604RmtdmOv7iMLg6URF+s3CNm1XgjkocLKFsFiflF0EPvF9cAljgDygLSOScQL9wsGSw89aeTieEnyFwjMVk30GwovXqwgoq7avm5xIBku7WVMoBX1BQ5G3YQ2YSHwGJZdwNkVpRXlThibPAhdtOfsnHJPUT/IXUTOlQJxuHAXcEISVBDBnC5Z+2nSpLu66pm77mmBqq7OFCNDTcPLK8vq0Jm8QBpGH+8HMn5TdAuJqOA== 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 SA3PR11MB8119.namprd11.prod.outlook.com (2603:10b6:806:2f2::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.12; Thu, 16 Jul 2026 16:04:23 +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.0223.011; Thu, 16 Jul 2026 16:04:22 +0000 Message-ID: <44f26cd4-be79-476e-b002-7ccfb7705179@intel.com> Date: Thu, 16 Jul 2026 09:04:19 -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> From: Reinette Chatre Content-Language: en-US In-Reply-To: <57740b97-80ee-4632-bca3-dc43cd7776c2@arm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0064.namprd03.prod.outlook.com (2603:10b6:303:b6::9) 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_|SA3PR11MB8119:EE_ X-MS-Office365-Filtering-Correlation-Id: e4e6e129-2e4e-422f-74ba-08dee353e6ad X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|7416014|376014|366016|1800799024|6133799003|10067099003|4143699003|56012099006|11063799006|22082099003|18002099003|3023799007; X-Microsoft-Antispam-Message-Info: Wme5AYB1Qmi/XC1visUp5tH8q8SQRJfSroJcsUCPsZrsz8FN6s5HX7O/FU8d5lAVuMCoaSge+GXUxdi3UEiwwJpwaJx4TgHsv9aCAwyDHjCQ5No/2o9ONu+cvvGOrcW6D7Ggf7jodLJQokzvEBy94DEio8VaJdXKoP5i10razyEA2KQse76vp4KwRAjzpk1zBjy4sii/vU3BswsA4ACzpDvqmeBU6HUbQ0/b/KPWPMG7Xl4BfKzYRms3PNkFMLQPbhjEqBUqp0tsynh13Y5L/R/JUhY9Qo1+NhVv/M6Xgd1WgRiO8oTkng8JPgl/dmryA/IwGgCMBmFSM8GKI+CT7TibeLb7uFSlqWL5TavhAy3w5fcWwSUn3qtLyJz62UZ5sxKheL41vRkph6E5k/CSijlgfpV3yBiaSAF9dPZXHFN5MwzjCXykVQB7m/gmuAwE0rGPK44ywrjunk00lPkZt/wenAglm7W5zQIy9Nr2oilvkILzCtvQ/nAKIDlGUdvk/yYqVClUHXaFbFiccJchpIUlLzN9mypDxHfU1fLe43lJJ4+DbEeKuR5AsgonHhckCc8J00N9a5/HrBrYc70gDtFC8Rj5Y6wOtnWJu42wkqD2Gdsoe4mNyysNdzjr/31c 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)(23010399003)(7416014)(376014)(366016)(1800799024)(6133799003)(10067099003)(4143699003)(56012099006)(11063799006)(22082099003)(18002099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VHJEWDRaYnE1Q3RVNjRkZUhRYTZZT0dCQTdWWXJFQWlRZlR6cTRzVkpoVWZS?= =?utf-8?B?SW91MnVJM1ZRZmN2TEpjdDZsdFNUZVFaSnl2MGxud09WSWMwNHcybWNWb3dm?= =?utf-8?B?Vmh3RGFUaTd6Y0RPanNmSHk2SENQZ2MyVUFlem1UTjA5OXpaRzl1WW1GOW9I?= =?utf-8?B?L1FHSS9ka0FVYThaVWlnTWxESG9jTDdSQ3lpNTNDN2cxOFZjSUJYbDgzOTlo?= =?utf-8?B?N0pkVEJXTXNlbXBacU4rTG1UdlByU2hwUlRrb1RHemludHoyRHUyWWF0Tkla?= =?utf-8?B?cFdnMmVKaGgvWnRvR1FRMHFPRU0rZ3BCSTk3VDRyVmthUG9PcXpISnAzQ3Vz?= =?utf-8?B?RkZwYTJhVklmR0lDem8vTlVpajUwQml4VkZ1a2VMWkZGKy8xZEVzL0F4SDZm?= =?utf-8?B?Tjl5K0czN05WWUQ2MDRZQWtVTkp2VmdwSkx6Q2FHMDlHNmpzVjZ6S1lJWWg4?= =?utf-8?B?Y0RIdjMrS1MybFYvM3BNeDFmMW9RZVlrSmFyUEJuSE16WkdTM21hTHZGL2xm?= =?utf-8?B?T1kxamxjQ1dJMnowVHdueGtrK1Z5UFBwZktkK2FENHJVRm53NlEwY0krdmVa?= =?utf-8?B?bko3RlRLSkVTbTQwR29IV0k3ekxtUjgwV3pKREpkV29vTTcxMHNRT1c1QXZp?= =?utf-8?B?bCttMTJ0VTFaTm5iYjUxV09jRHR3Q1lxb09yZU1ybXZYZklib0tHTzEyTWV0?= =?utf-8?B?TlFHVmJtYUgrdUh3ZUQyYWRBZ2NNTnkvVWhhNXV4ZTUwb1NxaWh1QlFKUzdo?= =?utf-8?B?UXlKVUM5YXU4NW11em9nd2pQTk44K1NmS1FuS2pmc3RuSWNvcDZoeXRzUWdU?= =?utf-8?B?eEZtN0VtenVmbVFFNTYraTY0MGQ0YTdSc053VHljdzFHdG16UjNtTFM1TkxK?= =?utf-8?B?ektqMkR6bktoRjl3YTdVeWg4ZlBLbldCN0VmUjNpSGh6c212aHg2MjdGUUl3?= =?utf-8?B?U2FPblVjSWRKbUEyTVJKSG1uZEU1L0w3Nng3cTVKa1pWeWtOaER0MUhKTS94?= =?utf-8?B?NUloZytoUU5ub2M4YXRJSHBsemtxbjRvMXUvcFBvZzNYb1k2UUxRNUVwT1Va?= =?utf-8?B?bnhMTTJjQ2pEOHl2cmErMHhMVFVxaEpnVjFWK0NOYmJjL2pIekhEODloNnhO?= =?utf-8?B?NU1sLzFrUmsxNkhzSXBsamtMeitTTmVxL0xsb1I1UGtXZzdtc28xY010b290?= =?utf-8?B?VGVwOEhIOGxaZ0dueEtaeE9mRlRoUG5JcVhtVXZ5WFlLbndiSWx5VmQ5Q2hp?= =?utf-8?B?NXJXZWxaM1ZNZUNjcXI5ZUdmT1h6YU03UWM2NUJCZ3FSRVhyblZuS0xLR0tm?= =?utf-8?B?cmZLQVpiVk54UUV1TjBVcGNOa0RrVzNXUWhNSkdFMSs3MHB6RmZ6b2hMWWJ5?= =?utf-8?B?d3pMTmplZktnMjAxM2haVlJPNUJ4UUVORFIwUlhCVXJJaTVKU0tCeWRCVUpM?= =?utf-8?B?bWVtaVZiakIwZlhGd1YyRWZvYUZBMXdIUjJ1a0FSaHZxWmx3T3d0U2k5UFVa?= =?utf-8?B?VitoTkpnMm9GNkxGUTZDcEcvYnZYVExlU1FqQVJiSjJlRkUwWnRxNkszVlhV?= =?utf-8?B?YTNFbzA2aWdWK1hRU2x2eEI0N0llSHdRZ3ZzbjdRbGxlNHVabnpmSVE4dzNV?= =?utf-8?B?L1YyNjZONk5RR2cxV1M1RTZTTmtMOTA0WHdNYWtDQ1Y0YkpzRmt0YVkvN29U?= =?utf-8?B?eHVyMHVIQXNESDFJZUFkeUdCQUNrUEk2dm84eVpIWTlka2ltWHZLZ0tMVkNk?= =?utf-8?B?WTh3RHZMT0NnZU5tK3VRVXZCdlErQ0NrMVBsVEVLQnRGTjB0WEVMNHN0T0Fr?= =?utf-8?B?RjBlU1V5SVN3MHJiaTlyT1RkN1dLZDdRTzF6TkI5dXF4YUxBYjgwdWhqTUVN?= =?utf-8?B?U1c0bzUrdUhMUCt4U2pWaHJZMzZBVHRYRjRJUERiS3ZjRnpwd2NlbFZHQUpW?= =?utf-8?B?aGVOMFN5eTdJZHYvM1pkWDhLcnA1bDhRMG5MN1lYMlV3aWJWN08vY05EQ1lO?= =?utf-8?B?YVc0a2pXcG1taC9lcVNWU1krWEFlcGVDUDF6S3dSeG5TWDhvditTSWhaUUYw?= =?utf-8?B?UmxYMUZOZ3o3dFcvOE5KNnVJQVIwTjhSTTY1UDU1TDgrT0Q2TjhER1lzL3hv?= =?utf-8?B?VGl0T0lxd0FQRS9CaG4vMWZRS0RFVDUxb0lzZ3htRXB5QUcxaHdSaTdRU0tx?= =?utf-8?B?bk8wdldSZFIyakZtTkRaSnAyMmxxbWJYemJmbFp2UEQ1Vm9TVFdrWEVQcThl?= =?utf-8?B?MytNcGRzbTJSbTh3OHFacHVjT1JHSU5wSURvUkV5VHcrZVErZTdTVzU5OU02?= =?utf-8?B?WnRWQ1JORXlUM1U3NWluRTlydGZpMWVaYmtBS3FLTHB6UGhPdkVBeWVBODdt?= =?utf-8?Q?KsQrNpHckZdx9hBk=3D?= X-Exchange-RoutingPolicyChecked: I7ppnld5xJ24ikFIpZEsECK+fvTHvkKUVewY3hDqNUVdhob2/pFLOuh8ljH+1P6bIYRc0nR4+b6Z8w6rUQic7a1RCrnuXxC5H0DJsPqzDOEKkDA8ERjO1Ry6RYlFyBOgLdrWYwAzXu4i4zqve2TphFRg4OBMuSNiJLdf6auvkWmIs2XGEyDnr/cgCyWXGRdvNV8EAdDL3Vkht/akPACDYlg73MYMUQvHGOEnGUpbRGCFQfB56TauQKAU8e6iaaZpb0hT60uf+Vw9/j4zmKB6Mh0pESBsgfifxGxrrmc9hUw/FmyxMwNUxdNQMhPZoXsada5Hs/aoSjScpjj9LN4VWw== X-MS-Exchange-CrossTenant-Network-Message-Id: e4e6e129-2e4e-422f-74ba-08dee353e6ad X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jul 2026 16:04:22.7452 (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: ooiQ4Za4rhQn5KjG1e/0vjdxn9LDazQHLK8Zjr3BLxAcgA3RQ7uTR3o4XwTXUgQEKkKYAqOTPhQdVEY23ZyBFP9YxfBEogfi0Mr4l+msTFQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR11MB8119 X-OriginatorOrg: intel.com Hi Ben, Chenyu, and Tony, On 7/16/26 7:59 AM, Ben Horgan wrote: > On 7/15/26 16:41, Reinette Chatre wrote: >> On 7/15/26 1:34 AM, Ben Horgan wrote: >>> On 7/14/26 23:06, Reinette Chatre wrote: ... >>>> Beyond this I believe that MPAM currently emulates the MB control with its "MB_MAX" control and users may want >>>> to make bandwidth allocations at the fine granularity that it supports. Taking this into account the interface >>>> may end up looking like: >>>> >>>> info/ >>>> └── MB/ >>>> └── resource_schemata/ >>>> ├── MB/ >>>> │   ├── MB_MAX/ >>>> │   │   └── scope:L3 >>>> │   └── scope:L3 >>>> └── MB_NODE/ >>>> └── scope:NODE >>>> >>>> A system like above will thus have three schemata file entries: >>>> MB >>>> MB_MAX >>>> MB_NODE >>>> >>>> Three schemata file entries would be unnecessary for users familiar with the finer granularity MB_MAX control >>>> so that is where the "mode" file can be used to disable the legacy MB control to just expose MB_MAX and MB_NODE >>>> on these systems. >>>>> Would that work for these systems? >>> >>> I'm not clear on the behaviour when the schemata file contains both MB and MB_MAX entries. I assume >>> we should expect that the user might read back the whole file, modify what they expect to change and >>> then write everything back. If legacy software does this and wants to change the MB schemata then >>> the MB and MB_MAX values would be incompatible. Will we just ignore values that haven't changed and >>> fail the write if two dependent schemata are changed at the same time? >> >> An alternative would be to follow Dave Martin's suggestion to prefix emulated controls in schemata file >> with "#": >> https://lore.kernel.org/lkml/aNv53UmFGDBL0z3O@e133380.arm.com/ > > I was aware of this but I had (mis)thought that the "mode" file was the alternative to this that was > being taken forward. > >> This was one element of original discussion that fizzled a bit since it was not obvious that user >> space would behave like this. Consider, for example, from Documentation/filesystems/resctrl.rst: >> >> Reading/writing the schemata file >> --------------------------------- >> ... When writing you only need to specify those values which you wish to change. .. > > Yeah, I don't know but it does seem like something a user could reasonably expect to work. ok. >>> Alternatively, could the "mode" file be used to switch between "MB" and "MB_MAX" and the two never >>> need be shown at the same time. The user opts in to using the new interface, "MB_MAX" by setting >>> "mode" and can just toggle back if they want to use "MB" directly again. >> Interesting. So far the "mode" options have been "legacy" and "native" where "legacy" would show the >> legacy as well as emulated controls in the schemata file and "native" will only show the new controls. >> resctrl could make the default of "legacy" mean that *only* the legacy control is shown without insight >> into the controls it is being emulated with. The only insight to this would continue to be via the >> hierarchy in the info directory, which would show relationship but not the actual control values. >> Do you think there could be a need for users (excluding validation?) that may want to see the underlying >> control values used to emulate a legacy control? > > They may want to see the underlying values to be able to migrate there legacy configuration to the > native configuration but they can just write their legacy configuration and then toggle the mode to > see the values in the native mode. > >> >> I assume for backward compatibility that "legacy" would remain the default so a possible inconvenience >> here would be that users familiar with the new controls would forever need to switch the mode before being >> able to use them. > > This does also make the new controls slightly harder to discover. > What if resctrl combines the two suggestions? Specifically, for backward compatibility the mode will be "legacy" and if there are emulated controls then resctrl displays them in schemata file with "#" prefix but not(*) support any changes from user space to the underlying hardware controls. This will make new controls easier to discover and let user space see the underlying values, but not break a user space that may read schemata file, change a few values, and write entire file back. How the "enabled" vs "disabled" state of a control works with this needs some confirmation since region-aware MBA support has this extra caveat of supporting MSR and ACPI interfaces which results in the relationship between "mode" and "status" of underlying controls not being consistent. This may be ok but please consider example below. Thinking through this with examples as I understand MPAM and RDT region aware so far. Could this work for MPAM and region aware MBA? (*) Should resctrl allow user space to change underlying control value of an emulated control in "legacy" mode? MPAM ==== 1) System default info hierarchy -------------- info/ └── MB/ └── schemata/ ├── MB/ │   ├── MB_MAX/ │   │   └── status:enabled │   └── status:enabled └── mode:[legacy] native schemata file ------------- MB:... # MB_MAX:... - In above, user space attempting to change MB_MAX via schemata file with or without "#" prefix will have no effect. TBD: there should not be obstacles to resctrl supporting user space changes by removing the "#" prefix. - MB_MAX control values would show the current active control values of MB_MAX control used to emulate the MB control 2) User space switches to fine grained controls # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode info hierarchy -------------- info/ └── MB/ └── schemata/ ├── MB/ │ ├── MB_MAX/ │ │ └── status:enabled │ └── status:disabled └── mode:legacy [native] schemata file ------------- MB_MAX:... - Legacy control not displayed at all - no # prefix RDT region aware when using MSR interface for legacy controls ============================================================= 1) System default info hierarchy -------------- info/ └── MB/ └── schemata/ ├── MB/ │   ├── MB_REGION0_MAX/ │   │   └── status:disabled │   ├── MB_REGION1_MAX/ │   │   └── status:disabled │   ├── MB_REGION2_MAX/ │   │   └── status:disabled │   ├── MB_REGION3_MAX/ │   │   └── status:disabled │   └── status:enabled └── mode:[legacy] native schemata file ------------- MB:... 2) User space switches to fine grained controls # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode info hierarchy -------------- info/ └── MB/ └── schemata/ ├── MB/ │ ├── MB_REGION0_MAX/ │ │ └── status:enabled │ ├── MB_REGION1_MAX/ │ │ └── status:enabled │ ├── MB_REGION2_MAX/ │ │ └── status:enabled │ ├── MB_REGION3_MAX/ │ │ └── status:enabled │ └── status:disabled └── mode:legacy [native] schemata file ------------- MB_REGION0_MAX:... MB_REGION1_MAX:... MB_REGION2_MAX:... MB_REGION3_MAX:... RDT region aware when using ACPI interface for legacy controls ============================================================= 1) System default info hierarchy -------------- info/ └── MB/ └── schemata/ ├── MB/ │ ├── MB_REGION0_MAX/ │ │ └── status:enabled │ ├── MB_REGION1_MAX/ │ │ └── status:enabled │ ├── MB_REGION2_MAX/ │ │ └── status:enabled │ ├── MB_REGION3_MAX/ │ │ └── status:enabled │ └── status:enabled └── mode:[legacy] native schemata file ------------- MB:... # MB_REGION0_MAX:... # MB_REGION1_MAX:... # MB_REGION2_MAX:... # MB_REGION3_MAX:... 2) User space switches to fine grained controls # echo "native" > /sys/fs/resctrl/info/MB/schemata/mode info hierarchy -------------- info/ └── MB/ └── schemata/ ├── MB/ │ ├── MB_REGION0_MAX/ │ │ └── status:enabled │ ├── MB_REGION1_MAX/ │ │ └── status:enabled │ ├── MB_REGION2_MAX/ │ │ └── status:enabled │ ├── MB_REGION3_MAX/ │ │ └── status:enabled │ └── status:disabled └── mode:legacy [native] schemata file ------------- MB_REGION0_MAX:... MB_REGION1_MAX:... MB_REGION2_MAX:... MB_REGION3_MAX:... Reinette