From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 D0AC5336EE1 for ; Wed, 10 Jun 2026 14:27:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.15 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781101642; cv=fail; b=CfTwjuRSFmE/ZKABvqU9Hu6tSLSQM0hx27gePzXi57oJXzr9ahIZ5fF/otZJ8FK1O746R2MpDxO8Mkz1U0XzfwurBEb7693KjDi5WOdb+wrP/bHlFDRIPyLdii69CUL+I7/POw0Yn+7qohNEZJ5BjBdcWRefDlBGg88FnCbnp1g= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781101642; c=relaxed/simple; bh=ZpQImMDz6WSWU0lIMle+hE5yM3BaoyvZxTNA6Js8A5E=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=Rxo/+fkbV+ORi09HGcu1HlJN2amfrPa0s6gTw/V8BMBnfHFCNzseWLWWHa/3K61NU0ZOhfWa/JGG8rex5TNCE+eOALohJLJa31HYaXyzWwguAmHifk/eVsCH8yYADCtJjmw2mhzem2S/Dox0n1X2LDZX+MK3lc/ovOrtMT3LOv0= 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=j+mzXt7y; arc=fail smtp.client-ip=192.198.163.15 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="j+mzXt7y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781101640; x=1812637640; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=ZpQImMDz6WSWU0lIMle+hE5yM3BaoyvZxTNA6Js8A5E=; b=j+mzXt7yvACrsGYuzj8qcEeB9j9s9y7k41OFKGj0rx2VWcpgRipEP6TS 4VTfSvaqZJd8V7JHEH8Znu9YTjUkzw6avVmyc0N1qGeZtQsFaS2t15EmU LXjwwQqN8MPOFZpRb93dV1Mosmif1LDdGMXjHHE+RS8F0bW1txYJgZaw3 u1WbvlEgjolNRpYUqfd+MwJ8Wp3qDRqHXRSDMcw5QL6RwEZKOl12tG1aV R8sszEIMwDKVR8UwAuSQUYpRSA5QbzaloQ6nOFWkqYiHALWwZ2kEtS3iV WAgmR9zWLN5J/12B9SpLh0axl44Bc3wjOFpoUy7hf3TT135jpAfBKN27/ w==; X-CSE-ConnectionGUID: lMM3RTCPTKuTI7mneL4gXA== X-CSE-MsgGUID: XXV/WPkVRcO1UtILOB+7rw== X-IronPort-AV: E=McAfee;i="6800,10657,11812"; a="82005165" X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="82005165" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2026 07:27:19 -0700 X-CSE-ConnectionGUID: oQ7b4v5LQ2ytIcsJhqB36A== X-CSE-MsgGUID: 0kwNod7LQn+/O5ZJU4RU5Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="251097143" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa005.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2026 07:27:18 -0700 Received: from ORSMSX903.amr.corp.intel.com (10.22.229.25) 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; Wed, 10 Jun 2026 07:27:17 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) 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 07:27:17 -0700 Received: from BYAPR05CU005.outbound.protection.outlook.com (52.101.85.47) by edgegateway.intel.com (134.134.137.111) 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 07:27:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=htTlGKqyEbo0DM37flZmS5I75JRfu7jCk5+L/+Z09OALJ36Ch6MautHX/BeoIpwDn8jDzWs7aMkCiLHr5WAffu6s1iDBrcWIdFobOqlMUhZH3oeEKJDGikuxJdmc3r4ESmlkxL+OwUOcIQF5dyLfCOwgHnD4OaKNIhICjBVY6GdhHoqlZ0Pl38eS8Rmvg7idFxb/kyebmc8EGgwQT9HKFhUtHrgE5cTpbDEBcI8wuiGGEbJiEZeiQIYeBUmXE8kKo8d+myuuucEWM3qQiJk4i8mmFTpSZJBIB7ReEA5pcjcOwy2yJJbNWR+aFB5TiFTu9163hfCBoCsmQvkKbutAMA== 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=++bFEKSlDbbO8d2gBjaJeYEEAkTB6deBqdH5G2MqGO4=; b=n8aQ6VzvhN4a6Yg/CaMB78nqwzbWGeZXk2vG24UytGFRXw64AwvDXUA9+yGqxhVJKtVtboCiG+1lxtan2L788k/x44DsddDsTRAoMc53U3SJ60NxfQZODTPIN3rVZBXjGrahEyp2tNJYKNOaPIpF9sjw6rj6X6NywPl629+Bcjk1wHzLMTuNF0MqM1A7WTxyvdQmqc3zYHOhOVkBxccGLbWjDQ3LQGrd/j5FZyPHPy0xZ/ppQLBoZeeUVQHGNwOhGPkcAFk5HDrueF2T8AQWyGoREY4M8ZwqiMM68Sij+jC0opWGOAiObg8jiViYo/ewxcOGwSpoZdTH3P26LfAH7w== 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 DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) by PH8PR11MB6855.namprd11.prod.outlook.com (2603:10b6:510:22c::10) 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 14:27:12 +0000 Received: from DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765]) by DM4PR11MB6020.namprd11.prod.outlook.com ([fe80::3058:1480:e4ac:5765%4]) with mapi id 15.21.0092.011; Wed, 10 Jun 2026 14:27:12 +0000 Message-ID: <68a07c57-6c69-4f67-8efc-c6c981fbb74b@intel.com> Date: Wed, 10 Jun 2026 22:27:04 +0800 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre 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> Content-Language: en-US From: "Chen, Yu C" In-Reply-To: <8bd94a5f-1460-4bc3-a2b2-68a298200ad8@intel.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TP0P295CA0044.TWNP295.PROD.OUTLOOK.COM (2603:1096:910:4::6) To DM4PR11MB6020.namprd11.prod.outlook.com (2603:10b6:8:61::19) 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: DM4PR11MB6020:EE_|PH8PR11MB6855:EE_ X-MS-Office365-Filtering-Correlation-Id: 742d0f95-dc0e-458d-cff6-08dec6fc5ca3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|7416014|366016|22082099003|18002099003|3023799007|56012099006|4143699003|11063799006|6133799003; X-Microsoft-Antispam-Message-Info: VDz3fw9IbEcs4ahk/t7nhCg8VNcabxLDmVjcuQhdE4rKK5iCtWIrzXNRWrpWuhVRd6KkWcvH1RYjR3r4VVONp8nC4281PyEEZAQL+zm+qO/i6oOq+oQeS9KVS8WSD23JujJLLtP+1vyd01Ar+pf/3DB4TSA1kUXILJlyQjHhbtrSV4ke9mZGV0TQg0f9CTBXTpMVSP7C2i+8e1aYPByPtn8uCrbEEjCfpaeejc7xCys7TDuuhS5ojNQeGrQjTS3ujnGcRJ/78BXNTHvesZnbtvKA6EpKqMs/Hz2KcpBnD8J4KyC4EhatMWLDUzogYJDl8xhXg/vmp7eAr6DB2vLQEJhV69dPpQGp5twT8WH+AUhYH8xMNoNHjL1SAsfEtxEFils98+nPfiR2D2UrXBMcuwDyGm/+JLYipR6q6nZSdEgegdLtOOEmJTH09gv7hdd8Lf+qND4AJEjW7ma5wJfmFnGXYygIwenwTvegeE0SNJtLJNBiJkBmKjuMSYc/3TGXe2a5gfamFrKMJV7QLsbxjVt6BY+vOEMSSu4pU8u4/JHleLw6y8EQ11KNPhdANloVsiGClDimBzES12W0nBTQjvZRY4lgj1onJD8iLOFKomnl+fqeJDuT1IigGnKyYnFlMStL8KRDyRmYMbqhYktMe93H8SxK09cm5FuyTovZQ1qooytE/TdIrFAVLMzNk5SC X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR11MB6020.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(7416014)(366016)(22082099003)(18002099003)(3023799007)(56012099006)(4143699003)(11063799006)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cUdnRDBLODZkWXd1Z0JIMmVSYjYvM1puZ2xXdnBnUmQ0WU1ISUdjWHFud3Vz?= =?utf-8?B?ZkxkL1BaS3kvTEM2MDU3YjYrbTRseGhkNTdRWTVjbGhrSzNUNzBnQ1FvODJi?= =?utf-8?B?NjU3VzAzWVJmSXRzWENzUTZkVFJBS25lRHRwQWdKTWJJQ1luTVBYcFNFOVhN?= =?utf-8?B?OGdhYU1SVXR3WnM3K3E3WlVXbVdJK3BVVm45cVlBMm5HWkNOTGFYZ0hvQVZH?= =?utf-8?B?Ly9pcE0rdXR5ZjEzT3lZZDdpSW5iY1k4K3BldjNVS3RPWDczM0FGakhzRTZT?= =?utf-8?B?a0NOTXRldFoxZzFDajNMYjFTM3hNdjB2b3RWMkpQZTFuSUdKaTJWeTJqWmhQ?= =?utf-8?B?TkJaZHJPRTJOanErK04yV1VSU291R0k1QWVaaE5wejJ5ZGJSTGJmNjJMWHdw?= =?utf-8?B?Y3ZmWWpwSVowUmRxekx5ejZZUHBBMTE1TlZQQ2F5ck95QzJYZGZ4VnR4ZjRp?= =?utf-8?B?alpnZlpnRHZVN0YwTE5OSnVPQVlXRy9WWTZET0dabWM3QUJuMmExcS96aEZU?= =?utf-8?B?a1M5OXZ4TkFKb0k3R1dxYmNkazY1MFBSSmpxalQvRVVkR3pUVHBrM1pJamVM?= =?utf-8?B?MXlocTZWQUFwNDdpL1hjeURVU21ncHRBSUlVRytMNEVRRVFNWGNQQkd1TU9h?= =?utf-8?B?bjY3cXFhb1pIZkhKNTV6K1R4VzgwR0MxMjJGaG16T1UxaWFLdEYyOHViMU10?= =?utf-8?B?TWUrTVN6SFJPc2FWVWxMYVMxMXhyb0lua0FtODFheWVudUZubGQzdmpXMGw5?= =?utf-8?B?Wkt3ZWNTTjdnUngxekxpZGE1Q1cvMGxMRUZmSXluUnM4WGxsOE5LKzFhd3pW?= =?utf-8?B?Z0pZeTRSbzZOUlpIOENHZG9NNm5VWDcwZWwrV3JwUDlBRSsvdGJNWE9KODl3?= =?utf-8?B?cTNlU2lMcXFNeVJ6VVcvbTNHWkVtL09VMWJMTnN6RmxaV3NyemVhMW85Q3NK?= =?utf-8?B?aHNBL0ZobGlnbnZjeGZvZFpxOEhrbGFaM0NHSXFxbndmZ2RDbmxCaS9CcU9Y?= =?utf-8?B?LzlwNGJiUzFuUVhmSlpnUWZpbVZkeTJJeDZmWFFOZkVqQzEzbVZ6RUpIUVFM?= =?utf-8?B?OGg3dDZsdlh1ZHRrejNveUtDL2VjemY3S1NhZkxrYk9rM3gxMnBqTDI0VUkv?= =?utf-8?B?K2VJYlRIdktRYmJzcDJuR0tuZ3pDYXJDb3FUWVJ0eHd3VlBES2E3V1dIMVBJ?= =?utf-8?B?VmhqanpFaWxkRjlHSDVsNzI0aUcwLzJCY0VIQXB3dmMvaGFCbWFQeFBZS0Z2?= =?utf-8?B?YXZtb3Fmbk52bUJ5M1JscDkybmt5VCsrSWFJNFZOV0hJSUtKUUhNNzU2TjZ0?= =?utf-8?B?RUhxbVBqL2cyZVlIWGhBS1JNS1RZcmxtMjV4a0hGRkRETUJ1QWh0RjdHMjJC?= =?utf-8?B?S3pXNTJWR045bEhZejU2dTNPNDFERmQvZEIxQlFyVzNHdHB3ZUNSYXZTK3VZ?= =?utf-8?B?SkFHRUxXYjhUOFU5Mi9hZkxTYSt1S1ZMRFdKOVo2Y29sMzVtVndiRUtScmJP?= =?utf-8?B?NU52cEE1ZFAvL3hwZnZPeXM2RElGZmhad2M3R3BQTmsxSTVNa1p1N1RHRkhS?= =?utf-8?B?S2gyb2ExZTM0K1FySVkwdzlVNVdsM1kvOEV1Vm93UGtTRk5IZFlRWmdEUVhz?= =?utf-8?B?cm1vTDg2aU44Smh0TVY0TE5qTXlTakhuekt6K3NsZXFCb1dDcUNYSmRrZmVE?= =?utf-8?B?Y2VreGd4eFFzOWxwY1JoYmV3aXJrTXR2cEkwUjFkYk80RFlWRmxiUkM0Z2Rx?= =?utf-8?B?bmpWeUxzYk5HeEZLbFNyZG1GdzZVT3FiRmxUNml0VTVDMWdDZXBsZHdHakFj?= =?utf-8?B?UmhVbEM3MndqWFNZM2FQY0Nad21wTlQ5ZlBYdE0rTGJkTWZvWGVSdU45Z3BT?= =?utf-8?B?eEJJaTVrQm1uVDZZbjdUSG8rdVlUOWNvMjJXekpLbTYxRHBZSS8wUzJDaGZa?= =?utf-8?B?UGxhaEJwL3RPUFBDRHcyMFZzOC9hYzF3VU0yTmFTTWxHNFZ3KzQ4L0RzNy9B?= =?utf-8?B?UXF6ZDI4dXFMTW54ZWkzM2xYbXJuUXRqczk1MkNOUVU0K09FMHRaQ3JFL3BH?= =?utf-8?B?WTVxVENweW9uVnl0cGxGMldtR1lVT0ZLd3ZrQVFvV2tyMk0vS2RsNTQ5MnBz?= =?utf-8?B?NVBscGQ5U3NIdGQwWGpNYVFkSmRjT0F2dktrbXphaVh4YVlIcnViV2Iwcm1r?= =?utf-8?B?L2NQMnFSbHZnM0NvbUJJa29OWkc5MDFpUWJmK1liaXpyRk15Y3lRWUp3dnh1?= =?utf-8?B?akJkS0NpMzdVVXRISkFJL0xRRmFiaG0wa2RFd0QvaWFMRkhjeXN4VzJ2WUhG?= =?utf-8?B?aGptL21OaGNZWkZpa1psaC9XUVFjTk9qci8xNDZCV2FLdE5WY2IrQT09?= X-Exchange-RoutingPolicyChecked: JDGoBtTpgQ+c6hNwxcLFUxpRznF3g5BZ1hH3LUWnYPNsMEHGkkq3EIkxG5usgln7dnqD284XWW8cMDTNy42TycbTOeqriyOegqRNjRV5qfyOZf+a3BeO6+P0QU3sttzfIiFHJarZ3dkU9/d61K6APQ5gDgEvesTp21A6gVEZ4gmxPP8H4Ybq9DTjZSmKzpOnTvvlJp9C6Y+W8WYeDJbTfyg0XGLDdH0aTBejQfdQmOdnnmKOSpswE9Fv5NJ1b4hbSD49Q8YeLk6SGHBWZMsI3Bn54zvoHvSGgG4SCCDRhM4sZKkJZjO1nD/7q4NIZvjbjUhZ0e630tgXwaDtqBeaLw== X-MS-Exchange-CrossTenant-Network-Message-Id: 742d0f95-dc0e-458d-cff6-08dec6fc5ca3 X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6020.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2026 14:27:12.2960 (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: i3OcVEM/JBWnkjT+6vE+a/9yzUqu4V6+mOjqx2nm1Wa6nzXzZEbL0kUIouFO/Lu70OF19WIJg4AxZZRDTFMwlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6855 X-OriginatorOrg: intel.com 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? 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 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) thanks, Chenyu