From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.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 717D5238D52 for ; Wed, 10 Jun 2026 16:13:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.17 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781108017; cv=fail; b=WDDVtGnYZ9nrabnzivOZCSA3ANTAluCU9lUzQiVL8AVZbe0tKhMui8bewbULh/68Qo70d2g/YIYXJDGAanBETZq6eMd5WcAuUpjPG9xyosj5lM27VzANb1+2J7Yha4Idswl85Z/bCzEKdIykQ1bQ3tSkTH0vonmLgnRZQTRTZ4U= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781108017; c=relaxed/simple; bh=ab5caEhtdj5ddjVm2IUmMV2eFrcui6a5AFwg2xAI+tE=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=bKwcq8uPMH8JOQZArx0kmKUKZbY7wduxT2FCIB5AzSbU1o3UBme/rgI37/liwrQv2DQpM1F57gUrdijrrZIOpGUBe9vhasT5159ZZp1zdhi3+Mw4lWHx0nTNzabKPwL4etkucxsN8HBQHfjkDigqakWPl7PyQkgl/MaHTpiEVLQ= 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=VxrRfZsE; arc=fail smtp.client-ip=192.198.163.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="VxrRfZsE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781108016; x=1812644016; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=ab5caEhtdj5ddjVm2IUmMV2eFrcui6a5AFwg2xAI+tE=; b=VxrRfZsEo15dvb1vrIJeRIU9pm5er0ajqL0gG7Bxe/GaGSA3zFAgDMk8 REFN3dST6PPMkvx9hHf84Cbo2VnaV243SZjXyRvMN3DiEzm/7ATYgZH+X yZrJkzg4DoqLRhkiQ/DlXT5o3AwEXUbtw4t/6l0aLwRq0m5XFROEjNfDl xrjKFae+yCVbB+Qs1/cJrgjDS+SB1TAPnWgMyH3DVE7Pfhh12Zu+SmbV4 kKCFE7KktDE5N4ToDSv5pddsxRhdkFKmqfKpwuELvOjl9V2qgvnKXWhMJ lrJ7vPe8yv5Oj4Vm+N0wlepbtAIOdl5ZzA9LqCOI7xt/pZIvNk8BjeJvd w==; X-CSE-ConnectionGUID: gH1jpr5lTqGRJQo7RQ8Ypw== X-CSE-MsgGUID: GOE4t9thRAmXki0d7h1sAg== X-IronPort-AV: E=McAfee;i="6800,10657,11813"; a="81753518" X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="81753518" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2026 09:13:35 -0700 X-CSE-ConnectionGUID: VLq0YYZZRFuxR0ejubFLAw== X-CSE-MsgGUID: HUCpvGCITT6WJ7GWJncoSw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="251299830" Received: from orsmsx902.amr.corp.intel.com ([10.22.229.24]) by fmviesa005.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2026 09:13:34 -0700 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.37; Wed, 10 Jun 2026 09:13:33 -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.37 via Frontend Transport; Wed, 10 Jun 2026 09:13:33 -0700 Received: from CH4PR04CU002.outbound.protection.outlook.com (40.107.201.44) 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.37; Wed, 10 Jun 2026 09:13:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=q84sJTBF3D8rMmKpPJ/gq+kQvm1pdJZ++m6nrsZCe2sOuNfYzbYT0vgo6fdZXdw0DZt7p2fk/tPI/41v9kKZAjIHmghyH0joAKAtVabsuFssS7Vw76tleuTE2HVh4402vlKQ1P9FQstMCnu5oqqbDsAjDvJL4MZ/Z2x8oVQCnl3iQscUHsHL9TqpbYBLCVbTVOBQCsOQAyPLDSaXuTf1UF+KtPREE/vUP8UVpkG2GfEBm7ut+MmedQXY4snS+CX8Hmo6qtZf3FxfTQxSghyrRVYHG49+xyHBOObF8wS4DHiPl/10wH8m7p4fIOUPoFa+5yTSmcfsO06RAz74c+8xYg== 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=sudGcR5mqJcI36K9I1BpNwgq7p4UIavq5AdYbeAqFBg=; b=PQ92UFIr7HxUlxfBh6jHnDGV82itZngADn7trG8DSaG4Uz0ITuKgqPOASvIyRhWci1ZTyU5DD1aL2pquQf3WIbpD/x7iT+ti+nZSZw2FUsyfHgzmfqbfgFHMgxSE8Alt0GH4KLBfsdPHtaasLMF2JfD1j/s6XFjJenu8vuL1VManLHXC5na/B3RO0nXob1URjesBFNK7CQ4c/TPH+jW5KXd2jE541anFjihQ4Q8VvCDVnfWpbqHCB+2EyGnJVw2sXUTQR+b0eIXu7U7vNtoQmIKpwVszzm7iEfuGDwB1UlLXJPw5Rz4ojU7a9noqWhoq72D5xl6+GfWhRV0LyDDJZw== 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 IA0PR11MB7330.namprd11.prod.outlook.com (2603:10b6:208:436::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.113.11; Wed, 10 Jun 2026 16:13:28 +0000 Received: from SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc]) by SJ2PR11MB8370.namprd11.prod.outlook.com ([fe80::b6cf:ce77:3cdf:7cc%4]) with mapi id 15.21.0092.011; Wed, 10 Jun 2026 16:13:28 +0000 Message-ID: Date: Wed, 10 Jun 2026 09:13:26 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: "Chen, Yu C" CC: Borislav Petkov , Thomas Gleixner , "Dave Hansen" , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Ben Horgan , Tony Luck , Dave Martin , James Morse , Drew Fustini , Babu Moger , Fenghua Yu References: <29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com> <7f2d0cc3-266c-4fa3-a9ba-7352325c76d1@intel.com> <3ef279c9-c4b3-48cb-8235-da8a871b54f9@arm.com> <5cffdb88-924e-43e7-84f2-ea19d82910fb@intel.com> <0c957e0a-0188-40c0-96e6-4e5d787a8ae6@arm.com> <8bd94a5f-1460-4bc3-a2b2-68a298200ad8@intel.com> <68a07c57-6c69-4f67-8efc-c6c981fbb74b@intel.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: <68a07c57-6c69-4f67-8efc-c6c981fbb74b@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR04CA0253.namprd04.prod.outlook.com (2603:10b6:303:88::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_|IA0PR11MB7330:EE_ X-MS-Office365-Filtering-Correlation-Id: da5897f4-438d-4c17-bfad-08dec70b3543 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|23010399003|366016|5023799004|56012099006|11063799006|6133799003|4143699003|18002099003|22082099003|3023799007; X-Microsoft-Antispam-Message-Info: 0yQGLrki0xdLRkeZtjsSGrhR3Wq3T/kPNAO3gURVhjrV35SkuKR5LeEdqqFYMMGc8QTJJzH1MWFC/4O98eXNAXbjUceR8VOD3L4B2Q4KCx9T4gz9xU9A8CwOupQoG8QQE3/oO5JgpsE3gfEEscXeaYSd+K1GCKN7cx5fODJqfZZwo0Tb6XIz9N+K5xREVwSX5DB8BT9PtvoOdDU77iILsm97kMEjEnZmirDfkO4+EQJhWKAmq+1x6Ty3ICYrt2NVIhObKOKMTE97xmhV6yqV686QpwRyamQDXIfye2wIhg+9wMDvNJ4AolM4f6bsBIjsP3GxGZtpdPFQiTm87Lp3qhV426lsZQAy0hBcO8+Lk2PWZV82jKFOvUtSlcA+Tnv0Ae4QOV30g8isvbN8s+vR+yk3VP3V7XFTfGjfYB6iIYVptz6nU0pxBksjENMjY1XXDQEnVvFFMe+eq4x1vJXkLi3rls9kQ1BQ6iwoQ4vXuXAgq1PLmtrKJdtHpb/Y0jmx8xSFweoaMcoy+LgsvSetThjp6JPNDbiCnXJ8BwXq2+LpcOhQgfQ3RxArS7FAHckapMTl398QaMH1kkgsCBtsXB2NqqD1J+Vyixk0dlN7yxPgkKmHaLP54jXZ9wd9TaRWUSvaG1A2vyZMUgNbFAauTQ2/fjCu8GLnhJenxDhERa1BUigRItHOslbtgfM9J//r 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)(7416014)(376014)(23010399003)(366016)(5023799004)(56012099006)(11063799006)(6133799003)(4143699003)(18002099003)(22082099003)(3023799007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RWtpbVRrdXU5clN2KzlTSGtvdVVZdVZwcjZLc3VtdkdUUm5zZEtGSmRqajAy?= =?utf-8?B?YjlNemd3djFDQUNMZFFHV1RZVnJJcGRRazhaL3N1RDV1WlZIME1qc3J1M0U3?= =?utf-8?B?MWVXQ2pVM1Q5SXpTMHNjKzVaWXNLdm1CTVdSNDJSbUtwajdxakljQWhsYnRN?= =?utf-8?B?SVBHbXZGUTBTRFArWnIxY1BZb3ZVakI1TUZxc2RGQzIvYzFPYlRqYnROaHVJ?= =?utf-8?B?QzArVk5tWkF5ZDdoeFNRdkN6Und2Yk9sMkFvcjcxYkdTcXhTNDJPT2RzRFFt?= =?utf-8?B?NjEra0c3VDduUk10K3RWSTY3eEVxK05iRFVBNFYycU9qZnpxUHExLzZnaUVa?= =?utf-8?B?VEE5RVQ4a1FTdlRrUDVFYnJZZE9wNmZTUEJOcEVmVHU4Mk95NEVjM283YzMr?= =?utf-8?B?YW81WUM3WEhMRjJJblpMeStzTWZucE5pbW1BNHhtK2VpTytLMFpsTlVzQ2Ns?= =?utf-8?B?T00xaHJPU2ZLVE1jOXVSSHQ1UzF1c0ZDQkVWODBMbGpWRDdWelgrSndqUUM5?= =?utf-8?B?MHErK0tTN2FPMFBNVG1NaVlnVDUyQzBMRGQyMDdWWUdOSDBKL0EvVzB2V1Z6?= =?utf-8?B?ekxJbDh6d2dtTGhNa01wSnZVMWExcTl6azJLeldhUG5Ybm81VnVTWFQySWMx?= =?utf-8?B?d01NNTQ5eUM4V295Y0ZqbG9sZnFBQUJhSEN3QTlvWVVJV0xTd3RIV1pVVmFE?= =?utf-8?B?VzI5dWlBOUk5b1Z6LzUwM2FBYkRFRkdtUjZpbU5GeGJEdWlMNU1uSCtCNGdx?= =?utf-8?B?Tzd0WGVaT2RxaVozb1RZK1JscXhuWUZ6cVkvQ0VUR09jZThtOWZkMDhyVHdU?= =?utf-8?B?MTdJK1pIMlQ4NWVnY3BBSEFBT2VLU2g5Q1NDWklrUzljN1ZSaFZMeUw0U1NZ?= =?utf-8?B?eFU5SkhCVEZDT3g1OVRicjQvQkRwcU9zRVVOTGY0UkdXNjNaSlhjelpjbU80?= =?utf-8?B?VnlIcC9HQU92cFVkY2wrSzBpR0pIN1g0eUJDa0M1WVRIbXRiVkR5bktuai9X?= =?utf-8?B?SVY1eEhKdmF5TzdOTHNtMnpRK1ovUGc5S3FZRFdBMllrY2VJRUxHZmxDWXJt?= =?utf-8?B?cDdrZHFXWWtYMTRmZ0huWUNSR2dpNDJkbnNMc2R3S2RURUxDY1VqNjBHUlBp?= =?utf-8?B?aE90YkxtMVozMUpkNG03Z05MdHBnMlc0OHhDZFNWM0gxcHNKSWNsU3BsYUJz?= =?utf-8?B?QzFRb0M4c0p0aWxyWUxiOHdmZksyTTE1SVJqZ2RSYzlENmo0dmtUaWROWjlX?= =?utf-8?B?T3BhUHovWWV0M3FscVRnY05tU3lRenJzK2xqUjJvcVIwM2ZGYndlWHRubG9y?= =?utf-8?B?OE5sNzJtd2VpaUdwV1R5bkZJVDh4YU0xTUdkdndPU1RPaG9sL1A3NG50NjFk?= =?utf-8?B?VWw3VWJmWWpiUi9WRDdOd3Nzb1JiTUN4a2hic1QvS1YwUlJRVDAwRUpMYmpD?= =?utf-8?B?U05YWUpKenFwbzJwS1ZZMzhtV2NoMnZreDdheC9vT080RzhBSE9zdldydktB?= =?utf-8?B?ZUxkSzZRVkFVaXZZLzFNNFM2TGdUZmlHTCszSGV0RVdYOEQ3aWNFRWtKUG9I?= =?utf-8?B?a0RFbjBWeFlkMlhnTG1NaG9YZGxtTlA4MjZoQ3lsV3h2a3docFR0dmY3VThQ?= =?utf-8?B?Yi9WaFJaVkx4alZQR01WZXBPdlJWOTkvVGZSU2Facm4xbFk3K3p2dkdJYUc1?= =?utf-8?B?aXRTc0JqdW0yQzV4aW13WFNENmpOS1JvOVY3dWh4Nlk5MnNldE4yU084OVlC?= =?utf-8?B?U0lJUHZRSjBxcWR0U05iNVpaSDJ3TUJKVjMzRXBmc0d6M3hCK0J6QjQrU1Rz?= =?utf-8?B?UUdncGtsTm5CcHQ5RkpWVHRsQ21RMzF6NzRTWkNibTRoZDhIL29iMFY5Y1Ji?= =?utf-8?B?WnFnUzI1UWxpZnVyazNydXJ6ODlCSFA3WmU1M2R0RVkwUVR4bE85WEY0QjAv?= =?utf-8?B?Z25acGlicEZJUjUrTFZNamhZclJqcUdwNEdMSDlvZEc4djNMY1JjQldFejNn?= =?utf-8?B?c3plVWh2Qnc2S3huejF4eGxJK2JSeExscnZXOEd2a01ZcUUrV0ptanVrUnM0?= =?utf-8?B?Wm9jbFY1WERTLzdZRis0cWdVZlh1dnFmT2pnN1VZN2RuTGVRWWtpK2orUmk2?= =?utf-8?B?RC9RNFJQNUowUUNQbEhsR0tIS3g1WFdaaHpJWkh4cExqS0k2a1RSS0xNSlUx?= =?utf-8?B?elJ5bTE5eW9uQ05HMFJBZUJLNFBoODJVanpraU1jYk5hWWNMNXJ6Nkd6aUQw?= =?utf-8?B?a1NvM1RHODU4UkFQZFY3RFVpTzZrVUxXdG9Lc1dmQ1RBZjF2SzhVNk9BMDAw?= =?utf-8?B?b1VlQnJpV0RZZS9sc1dHYnNreHZHamlxRHEwd0NuVUx4Wk5BOHZUUHhyR0Vo?= =?utf-8?Q?+Mnm8Zp/v0M/HYQc=3D?= X-Exchange-RoutingPolicyChecked: LdVC/gKKZegrRxL7Y/esmETqyzq/2POhElsbs7NaesooXijQKxhsZSDOlEj/R0L/6NyI5sSN+g8DBPWTxvwHNQt9QsuTfNfJf+arTsgasx5ARkWLqo4OqVOi/ykgG1ERYPHXki+f1SnfiocZ3CMLICLQtzhfwTEglOF9D5rWLXtZ2oFDoGlEhWPIJkt+izVXgSxcck+MPUTiW53A3pm8zh07+QG65MDf4a8kCVxsvvCaCQKwrCKHp1F7xuAnLqdpzQFAbQZYgS7KAzCZ3ICEPZBheCQBmcj2trh2K+gYw0mYrX9Jq0ti/MJNIbJYAQ6j5KPO17h8Yh/eMmgTJbxW0g== X-MS-Exchange-CrossTenant-Network-Message-Id: da5897f4-438d-4c17-bfad-08dec70b3543 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2026 16:13:28.6977 (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: c0wgJQNbOlWS+U5bSD8A/Zv3VkIVDLNU2qgBM11TGKgbr8drWaL+ct8pcK2SqkGE6sYBQbLr8xBwE6EyIoc2Icmt/yJZ1M5V9Csyvo3MuxI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR11MB7330 X-OriginatorOrg: intel.com Hi Chenyu, On 6/10/26 7:27 AM, Chen, Yu C wrote: > Hi Reinette, > > On 6/10/2026 3:09 PM, Chen, Yu C wrote: >> Hi Reinette, >> >> On 6/10/2026 1:41 AM, Reinette Chatre wrote: >>> Hi Ben, >>> >>> On 6/9/26 9:37 AM, Ben Horgan wrote: >>>> On 6/9/26 16:28, Reinette Chatre wrote: >>>>> On 6/9/26 3:10 AM, Ben Horgan wrote: >>>>>> On 6/8/26 17:16, Reinette Chatre wrote: >>> >>> >>>>>> I don't see the advantage of emulating MB with both MIN and MAX. Just going by >>>>>> the MPAM specification, a system keeping MIN at 0 and just setting MAX from MB, >>>>>> (MIN=0, MAX=MB) should behave the same as one always setting both, (MIN=MB, >>>>>> MAX=MB). In the MIN=0 case there is never any high preference traffic and in the >>>>>> MIN=MAX_MB case there is never any medium preference traffic. It seemed best to >>>>>> not rely on any platform specific heuristics to try and guess what's better and >>>>>> just wait til the time we could support MB_MIN in resctrl (and leave the >>>>>> decision up to the user). My expectation was that this would be the simplest >>>>>> course of action. >>>>> >>>>> This sounds fair. Two observations: >>>>> - The hierarchy exposed by resctrl may be different on systems that have the "same" >>>>>    controls. >>>>>    For example, on an MPAM system (if I understand correctly) the user may see: >>>>>    info/ >>>>>    └── MB/ >>>>>        └── resource_schemata/ >>>>>            ├── MB/ >>>>>            │   └── MB_MAX/ >>>>>            └── MB_MIN/ >>>> >>>> Yes, this matches my understanding. >>>> >>>>> >>>>>    Compared with a possible implementation on Intel that looks like: >>>>>    info/ >>>>>    └── MB/ >>>>>        └── resource_schemata/ >>>>>            ├── MB/ >>>>>            │   └── MB_OPT/ >>>>>            ├── MB_MAX/ >>>>>            └── MB_MIN/ >>>> >>>> Not sure if my understanding is correct here... >>>> In the kernel today is it rdt max that backs MB? (Ignoring the sw controller) >>> >>> resctrl does not have support for the RDT "MAX" controller yet. Since resctrl was >>> created as part of enabling RDT the resctrl MB control maps exactly to RDT's >>> original percentage based memory delay value that is an approximate. Newer hardware >>> support three controls: optimal, minimum, and maximum. These controls have finer >>> granularity than what the default percentage based control supports so emulation >>> is needed. >>> So far I assumed that on these systems the default MB control would be emulated >>> by the new "optimal" control but after these exchanges I can see there being an >>> argument for it to be emulated by the new "maximum" control also. Apart from it >>> implying a cap there is also the idea that the "maximum" control is more likely to >>> be available on all platforms. >>> >> >> Regarding the region-aware RDT case, I wonder if we actually need to emulate the >> legacy MB control using MB_MAX. First, when we refer to the "legacy" for region-aware >> RDT, I suppose it corresponds to "MSR access" plus "percentage-based control". >> >> case 1: >> If the platform does not support region-aware RDT (no ERDT table is detected), >> the MB is naturally the "legacy" MB, and the info directory would look like: >> >> info >> └── MB >>          └── resource_schemata >>                  └── MB >> >> case 2:If the platform supports region-aware RDT (i.e., ERDT parsing succeeds), >> then the structure looks like below: >> >> info >> └── MB >>          └── resource_schema >>                  └── MB                  <=== legacy >>                  └── MB_REGION0_OPT >>                  └── MB_REGION1_OPT >>                  └── MB_REGION0_MIN >>                  └── MB_REGION1_MIX >>                  └── MB_REGION0_MAX >>                  └── MB_REGION1_MAX >> > > This may be slightly off-topic from MAX emulation, but I have another > thought regarding multi-controllers for rdt_resource: > As we know, with N regions, an MB resource will have a total of N × 3 > controllers. Given that the current PoC iterates through every controller > within the resource in resctrl_resource_ctrl_get(), could this increase > lookup latency? resctrl_resource_ctrl_get() is only called when the user writes to the schemata file and since user can modify any of the enabled controls with a write to the schemata file it is necessary to iterate through all controls to find a match. > > I studied the cgroup code and found that each controller for a cgroup > resource uses a dedicated cftype. For example: > static struct cftype memory_files[] = { >     { .name = "min",  .write = memory_min_write,  .seq_show = memory_min_show }, >     { .name = "max",  .write = memory_max_write,  .seq_show = memory_max_show }, >     ... > }; The PoC currently has "static struct rftype ctrl_files[] " that associates an rftype with every property of a control which enables all user space interactions with the individual controls to be direct. > > The min/max memory controllers can be accessed in O(1) time using: > of_cft(of) -> kn->priv, and cft->write(of, buf, ...) > > rftype is resctrl's equivalent of cftype, and schemata is currently implemented > as a single rftype. Would it make sense to define a separate rftype for each > resctrl controller(or maybe in the future consider that this is not in a critical path) Your suggestion is not clear to me. The schemata file is associated with a control group, a resource group that has multiple allocations each backed by a different controller. I do not think I fully understand your suggestion so would appreciate if you could provide more detail. Reinette