From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 114B2456DEC for ; Thu, 23 Jul 2026 16:18:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.19 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784823523; cv=fail; b=VGp04OEp4JUgLDPl5gEK0eKRtYsqG+OGsjCdygFosrF5j0hH9gdL2Pxn9tHKma78l1+cnHWVFJdfwSuHb+jGRxN8N1+WeAWu7cjxrJDus48qEsck0P7rfamhu1HslHtMR0eJXSVzvMqL5F8BVGMcFdM36IThGuW146JisXS1ENU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784823523; c=relaxed/simple; bh=StZHq2lme4w4lv7pWY0uu2tIFyHtN6xnkBHUGl4HDmo=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=t/9YqxZCer8M6SJq8y0hbwLBoAnEBeud74zXegal8DuGC0iEfRgYUWT0Isp44HmBfcczkomgwXgm2wzd3vLgNcv7MIJlmUhYc30TjgwLyoEB4jsoOZUbT5+uqGwcf74kP3XiMygVHI3F5TkXhjuytlySp6D4J4NTI95+rl+4BxY= 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=c8D7kkoh; arc=fail smtp.client-ip=192.198.163.19 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="c8D7kkoh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784823513; x=1816359513; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=StZHq2lme4w4lv7pWY0uu2tIFyHtN6xnkBHUGl4HDmo=; b=c8D7kkoh/YaNNss7yliwVgYiw1gBQM8UUhdz6rdJ8Nko+tgLEjUq6eqi zbed6HCnQCrRjZbTglTxGnJocwXW5AaMCao6CViBBdJ03exJYSylA8guR C38qlFuGuDzZ47gsD9cm3Lc8odd4KrpNPY2uRWrpTQQ47K6jkuYxD8/Tg blh9h/KcHV6LnK9FqV5tPXe00VfQamXQ9om/mGbGnBjxVAvMCRDZ2Awn2 zebFvyC17uLglICp2sg9QRMF+Su87GasKCH+t8jRpdyJEm6SuCshwG/OY 4pkIN0ZkXaBcMB394K11nH2EJ4ArQ63F8TQscCetOyWJs+NCSyj971P3O g==; X-CSE-ConnectionGUID: VCvmkIUdSq+eb0+j64IJIA== X-CSE-MsgGUID: Qgpx8RfxRvO5NKnb8r3buQ== X-IronPort-AV: E=McAfee;i="6800,10657,11854"; a="84461384" X-IronPort-AV: E=Sophos;i="6.25,180,1779174000"; d="scan'208";a="84461384" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2026 09:18:27 -0700 X-CSE-ConnectionGUID: /4e4hZy0QBGwOL0mIwTZmQ== X-CSE-MsgGUID: G73jUMh6RPOkRfA8iJRTkg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,180,1779174000"; d="scan'208";a="282960871" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by fmviesa001.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2026 09:18:27 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx901.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Thu, 23 Jul 2026 09:18: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, 23 Jul 2026 09:18:26 -0700 Received: from SJ2PR03CU001.outbound.protection.outlook.com (52.101.43.19) 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, 23 Jul 2026 09:18:24 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=AbCfKVlvVzBBjvJZq8HjMiV2MaTgYUkiANJV4723LdfVNcw3X5MWqLU2EPr5//OYuikKT3CLH0UX2ANm444HWMlaUpg+C0P010d495lfRPKD2tALiA+O1koSgd/trhQA8varfYnF+5Abh1KQYk58U1I026++zjnd3mJn/SvWZLsUAF0o/OoRqZ1pTatiXdE2KhkAMgxbY017Dk7rP3uMt1yY9GeLMkdmB/fiTwyrtxvVoa0BcPF5X6vfZziPlqLrttYzvSkYsmbC0idkZYw0wwToQR6ZKhUyIcGezqLLRlYA4pq83qDdYxMoUsacMSOPJdU8mjBnPmFOxzHs1DVrzQ== 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=A/m5beZrD/UM49G+9f+TQwZ49FQ6z50+9Hu04fqtYOs=; b=aLuB6qcgtDDqPdtHzDbh7RoTnZJsGH9Ajcy57zmcgjbbyn0TW+SG3GmvfU3wbFRBvqlCoQNw3mepEvNQvtmwBVNZtPTNOcxt6i1pFip1Y/C+mZTqBobXfffy5nwA7lwho3X5V6sgNo3Z3NBA3HdfB1+pkdjE6fTVyVPhu9LAh3PCyk7ylWviGVAr0FKD+dIgXnWTGg1HtucRLFlKlAFNVgOajWDowubEBf9d7n6cTRL5CM4eqFHAoIQkeAlrFTgB/Th42xNNaWjwShTRjfaa18Z/+v9b5Ws4hkdVnPfIVwOeLj+Ko6Q+fyrzbqqklMvLxBDw54rzUFp/qYVHsnOIIg== 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 SA0PR11MB4749.namprd11.prod.outlook.com (2603:10b6:806:9a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.18; Thu, 23 Jul 2026 16:18:22 +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; Thu, 23 Jul 2026 16:18:22 +0000 Message-ID: <917ef5ed-c720-4afe-aee6-3ec201e565e0@intel.com> Date: Thu, 23 Jul 2026 09:18:20 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Fenghua Yu , Tony Luck , "Ben Horgan" , 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> <9425e9fc-36cf-44cd-b6fd-88b76d106eea@nvidia.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: <9425e9fc-36cf-44cd-b6fd-88b76d106eea@nvidia.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0013.namprd03.prod.outlook.com (2603:10b6:303:8f::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_|SA0PR11MB4749:EE_ X-MS-Office365-Filtering-Correlation-Id: df3e193b-93cc-49e8-289a-08dee8d60441 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|7416014|376014|1800799024|3023799007|11063799006|56012099006|4143699003|10067099003|22082099003|18002099003|6133799003; X-Microsoft-Antispam-Message-Info: 83RkSKwzG9ve4Kh46oC72xS6bxbv7wMtssU7F7upG6qxy0x5cuGgZ9gCD+P/pqyTarqTAqhiuVJm8xGFFzZs8a5Filv/ccAQ1ssOrH2glKg01Vslwf8DHL9BJrwu2qOOmfd0ETfI01jSrMk/XRAfBVRavQVBPGuR6hzLySKO3ajnvZwtfjwwJZCgvTKRPdZT1IqxC1eMJLinWKZsk4GUP+SHzgvJN32brBzCTHLojjUu4Vc2H9BJxBaLnf8nchdjjzm2fpZ39/F18RgUfzNte4a2wTppuofqz9GGGoPT5UapSK7ZKEtK7tFcCAhox7bHaenGatKTpirVoW6wSS0PWQ3cgza8IiJACWlPUNflGRBKlnN/QTcvBxZmJ2v7WnxSZBfXTM+CZ7aDllVw3Rw+ljlIrU6s1xOhlh1UPA7RJMm/AuMS13kEEwAc9HgU+L4yI2OE5h0iBuPSoJi4gRDxFV0pBK5rTx7DeMbrI4hhyCJJXMJKjXieF7GrcNYiD/WcT+cyqS4UPp8JtlcYu30xWFzqLXNK0ZzvNg9wRFikspy3rfiwIRhMnNhM3+FgJFjdWDhIDF/j0f1wB/vRXMv4yS/FVosKOixSZjGaRB0OEgehhA9zSxlQJWwFybLEdYpgmpw3Yh305ks/gRBlY4nts5gTBRDmJjaSVjR6cMvuMIg= 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)(366016)(7416014)(376014)(1800799024)(3023799007)(11063799006)(56012099006)(4143699003)(10067099003)(22082099003)(18002099003)(6133799003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b1hkbmFTN2VwNVpEaXdqeno4S3ArUFVuZ29rNGpKdmJadTVWMFI4RnRrRERF?= =?utf-8?B?YmVQYjhUUDloSEtRNGJHWEVKYkorMnVmSHJNbWNGZkdOaFg3VHFCdzJVRnYx?= =?utf-8?B?YmpwdlU0VlBUS0Qxc3J6am1hQndNblN5UDdCa1QyUURlY3hJVUFldVdVaUxl?= =?utf-8?B?UXlicVNIczdVWlYrYXJLdkhIVnVwckdLTFlKenRlZlFmUVFCYzNzcytqQldx?= =?utf-8?B?S2tYS3h3SUFueThvMlpLc2lUeUQ3bkdzNkxVOVlPNDVoVHpHS25MWmRiT01P?= =?utf-8?B?aTYvK3dXajBwclJpTk45djA5aFJ5ckVFWDBleWRJNmRmZ3pJU2gzZkxtdnVa?= =?utf-8?B?Zmp6U1dpZFRjQWYyd1lXTVhka1hGekF1R0FYbXhDTVBaRTRWSlVGRHZkTkc0?= =?utf-8?B?czZzNzVYakVTVFptNkVCeXZlVlBJa2k4N01hUjluLzlFYXNFTzR0RmxYQmd0?= =?utf-8?B?QWxtbmR1SU5pNFZwY0J1K2lSZ1A1QjQzVFZqVUcrSVo4VDNuSXdicjh5V1p5?= =?utf-8?B?TVJySGNpQWxNdXdqTDR5YmQvNC9hdFFnazA5VG1pcjRXUzk3Y0tsSEhUSDJ6?= =?utf-8?B?SWtIRzJtTFd6RGdQYXhuVHRzUUN1MzZWMDZiaFJ4V3phYjVzekNkTE1rcG81?= =?utf-8?B?SFo5RnJYUVZnaW1rVjd3R2RNdFUxS2ZPdXM4ZVRSMG42RXRJZWlCWDRyL1li?= =?utf-8?B?SFpXcjFIMWZuUkRnMXZKVDhYallWSVVQaHhrU0NydzRXUXdaVDJXaUpPUUxr?= =?utf-8?B?YWRpNk4vb2pac2I2VVd2Sm1lZ3lqVDVrbEJoSWNOVkZObVJvUmhuZ0RqQVMr?= =?utf-8?B?eE12elloY1FGMEpHeWkvVjFuSy9hTE1LYnVLVjVyWEJOOFJNR0xXSW9tNGYy?= =?utf-8?B?NlJWTUxGUy9TdVNaRjEyWEgzeU5zZ1A2TzlVSEpCbG1PR1MrdXpVb05uS0FP?= =?utf-8?B?SDZNQWM3Z3lPME1pcnFncC9NQVVPRDM4ZGMzbkpFOW01RmhUU3BtYXFFdzQx?= =?utf-8?B?dHBPWHkrMmY3MjcxblBGSjVOT2NTSUxKWFEvZlozZkYweFdBTlgzaVphUDdR?= =?utf-8?B?NnJ3U04xQlNQWFMvSWM1YUdiZWRiNS9nbVRNSnJPcFhVNkM4VXdod210RERi?= =?utf-8?B?aHhtcVVTYVlkZEtTa1EyM1hnOTJsc1BhRjRjOURNTURUZnJLNnViNlNacDFN?= =?utf-8?B?VkRGOElGditMUU9HMWZyNkhHSmxTemU3YzBvMnQ2Ykt3YlN2T1ExUDlhSEkw?= =?utf-8?B?ZXdHYUZVTFNIMUJNTGVpUEEvMElnVm1tenorVzNvYStrUkZUdHVZbzVheVo2?= =?utf-8?B?M05zNnRuUmNaVmpvTmE0Tk4rQlkwcC9OTGtmSk9QVlRCcUNENlkrMENJOWMz?= =?utf-8?B?MjZRLzBNbHlzWmN5QURSbjdFQmtiZnlKNlkyTEEwSkc3TmgySXJFWlg1QnZW?= =?utf-8?B?aGNjSFJaWTZnWi95ZUYzVUdjVVlRU2dZbzBpbUtQVktsY2E3NTh3Tk94cjkz?= =?utf-8?B?dlYwSkFob0p0eWxzem92WGEzbHI1TncvTjBML0RlUXZpUVlJU2pRMkM3eW1K?= =?utf-8?B?SFl3a0o2dWRyYTVoSEl6NDFLdTlWeGx1SGpBYzBUengvaVhjMmJNVFJDYSsz?= =?utf-8?B?ZkQ5ZGVXbTdQOXJBRDVwUVVoSGg3TEcrQTlEY3RZRXpMV29uOHc5SGJhMnkx?= =?utf-8?B?Y0paSEpJc2NVV21TbERLWCsxZnRJekpPdGhqOFNNSis2dGNyS2lMdHc4aHNs?= =?utf-8?B?TnBKT2ZBMW13NEVOSTJCV0xndEJpNFdiV2hNczE3WTZ1UW9NSUtaSDVEaklR?= =?utf-8?B?Y3p2MnhKRnJZdEJRSGtWQjhvV3drd0pZeXc4bS9TM1JDVXBpYjVoeXdMY0Zs?= =?utf-8?B?WERPamgzYlVOd0E1ZFgwRXBmTEttUlhWRC9Eb002a2JnR2pCOFFLVzRKd00z?= =?utf-8?B?YjgzdUhGWDhZdXNQTUc1djJjY3lVM1BOc2Q4eUN5b05GbzhLYW01c2FNTnZU?= =?utf-8?B?ZXZDekt0b0FnSXdTeUo1RmRNT0NiN2tWSlZxQnFqS1ZwclVpT2pwaGJVU3lt?= =?utf-8?B?WTJIWHpGT0xZZUlmZTg2OUkrL3o5UFYxYmJrL040UVpaNUFJR1RiMjNYSito?= =?utf-8?B?TkR3QlhYZHhyRmhXZ1U4SjdiMW9aaTZjdGdldFNSeXZhN2ZudEl6alhVZHBB?= =?utf-8?B?bzYxazVqRCtXbyt3bDdzSWd4VnJMNWpIWDZHYUtNcDFVbjMwc2dMeWlmbk9D?= =?utf-8?B?VkxzcnZhQXhCSzhJeXNlSXk3QUw5K1Z2SkI1M0t1bzVONzV1VnZWZzNhb3k1?= =?utf-8?B?M2xwamVaaXdLMERra3VUUFVrTERHeVpnL2NINytPM2JRZUp5RGZlZUJKZFlV?= =?utf-8?Q?osYKrCThRS2izR5M=3D?= X-Exchange-RoutingPolicyChecked: Iny72iDl5mEjobrKvN45M0o3RxmLANV0KO2ZXuQ79kgI9tcbVpSXIpHvWO0+T/9p3hXc5CmoLqCheltMvDd0FtMMj1H7Lt37AHfdiwxeaMHxN4hiv/gaQrcuxtfKGgj9zu/IaGDZAczKHCtJdPcgV1M5A7x/0R8JY2hwWEdbCqHCnPRU2JBr/zHeGoDUw3QvFu56cIiloCSEMp5YbbP5SkKejkx3EUD/o45OEeAIXr/Yusuoy5lx5IHUpgggBiSCiEqg1gDSa7K1YsLT2eaIfcKpgG5yG01rA9FDcDK0GGNNuLXwfrZGjysgtdJklyEEBLKG9D2bv92Si6KIa6RuMA== X-MS-Exchange-CrossTenant-Network-Message-Id: df3e193b-93cc-49e8-289a-08dee8d60441 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2026 16:18:22.6682 (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: GXtKV33h3Xohs7+Mv9TjAqqCO2N09UHfiIeghRe64z2iOkH2Ca38p/71pghEdsTupDNo8i124+t6Ty3EqggVRnNqHHMM6ojhioTlI1yqzBg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR11MB4749 X-OriginatorOrg: intel.com Hi Fenghua, On 7/22/26 5:17 PM, Fenghua Yu wrote: > On 7/14/26 15:06, Reinette Chatre wrote: >> On 7/10/26 1:59 PM, Fenghua Yu wrote: >>> On 6/25/26 08:43, Reinette Chatre wrote: >>>> On 6/24/26 6:26 PM, Fenghua Yu wrote: >>>>> On 6/24/26 15:22, Reinette Chatre wrote: >>>>>> On 6/24/26 12:08 PM, Fenghua Yu wrote: >>>>>>> On 5/29/26 11:06, Reinette Chatre wrote: ... >>>>>>> 2. /sys/fs/resctrl/info/MB/max_lim >>>>>>> It shows number 0-3 for MPAM MBW max limit behaviors: 0 for supporting both softlimit and hardlimit, etc. >>>>>> >>>>>> Again this adds another *global* property to the MB resource but then above you >>>>>> describe the new "MB_HLIM" schemata file entry that implies that it is a new control >>>>>> for the MB resource. Having it be a new control for the MB resource matches earlier >>>>>> discussions. To support this I thus expect it to be exposed as a new control with >>>>>> potentially a new type if any of the existing planned types do not suffice. >>>>>> >>>>> >>>>> How about adding these MB_HLIM dir and files in info? >>>>> >>>>> /sys/fs/resctrl/info/MB_HLIM/resource_schemata/MB_HLIM/type: boolean >>>>> /sys/fs/resctrl/info/MB_HLIM/resource_schemata/MB_HLIM/max_lim: 0 >>>> >>>> This presents "MB_HLIM" as a *resource* to user space. It is not a resource >>>> but a *control* of a resource, no? I thus expect it to instead look something like >>>> below that makes it clear that MB_HARDMAX is a control of the MB resource. >>>> >>>> info >>>> └── MB >>>>       └── resource_schemata >>>>           ├── MB >>>>           └── MB_HARDMAX >>> >>> Yes, this makes sense. I have changed to this hierarchy. >> >> Thank you very much for considering this approach. > > [ MB_MAXHLIM: I use this name for MBW_MAX hard limit feature as Dave Martin suggested before. He also suggested MB_HARDMAX. Either name is good for me. I use MB_MAXHLIM to explain MBW_MAX hard limit for now.] > > Some implementation thoughts: > > MBW_MAX hard limit itself is not a MB control. Rather, it configures > MB control, i.e. turn on MB control's hard limit or turn off its > hard limit. So MBW_MAX hard limit doesn't have properties like > bandwidth_gran, delay_linear, etc. MBW_MAX hard limit's property is > only a boolean type. "MB" is becoming more and more a software concept that represents memory bandwidth allocation and in that sense I agree that the "hard limit" is not a "MB" control. Even so, since "hard limit" needs to be exposed via schemata file it is *a* control. This is because as part of exposing it via the schemata file it requires the following: - a "scope" that specifies what the "domain ID" associated with this control in schemata file means - "domains" to be the list of domains, one per "domain ID" from "scope", to contain the staged values that user space provides when making changes to this control - a "name" that is presented in schemata file - resctrl needs a way to pass the user provided values to the architecture for programming, the API for this is to pass struct resctrl_ctrl. You are correct that none of the current control types are a good fit for this new boolean type. resctrl would need to support a new boolean control type. Ben and I recently exchanged a few ideas around this. Please see the thread that starts with the message below (search for HARDLIM in the message): https://lore.kernel.org/lkml/34b95afb-8b60-4680-9ad1-90c5b24e8fb7@arm.com/ > > So I would think it maybe a configuration inside a control. > > Similar configurations could be hard limit for cache capacity in MPAM. > > Maybe can add "configs" inside resctrl_ctrl. Schemata and info/MB/ > resource_schemata/MB will show/write the configurations per control? > > For this configuration or future configurations, add "configs" list in: > struct resctrl_ctrl { >         struct list_head        entry; >         enum resctrl_scope      scope; >         struct list_head        domains; >         enum resctrl_ctrl_type  type; >         enum resctrl_ctrl_name  name; >         struct resctrl_ctrl     *emulated_by; >         struct list_head        configs; <--- Add configs for this control >         union { >                 struct resctrl_cache    cache; >                 struct resctrl_membw    membw; >         }; > }; As I understand the idea is that configs is a list of struct resctrl_ctrl? At first glance it is not clear to me why the additional layer of abstraction is needed. What do you think of Ben's suggestion in thread I mentioned earlier to instead name the control: "___ where is HARDLIM" (nit: While I understand HARDLIM matches more closely to MPAM spec I do find "HARDMAX" easier to understand) The additional layer of abstraction would require both resctrl fs and the architecture to dig through two lists when handling these controls and it is not clear to me that this is necessary. > A resctrl control can have one or multiple configurations. Currently > MBW_MAX hard limit is the only one. But the infrastrucutre supports > multiple configurations per control. > > schemata: >         MB:1=100   <-- MBW_MAX on L3 id 1 > MB_MAXHLIM:1=0     <-- turn on/off MBW_MAX hardlimit on L3 id 1 >         L3:1=fff > > info/ > ├── MB > │   ├── bandwidth_gran > │   ├── delay_linear > │   ├── min_bandwidth > │   ├── num_closids > │   └── resource_schemata > │       ├── MB > │       │   ├── configs > │       │   │   └── MB_MAXHLIM > │       │   │       └── type   <--- bool > │       │   ├── max > │       │   ├── min > │       │   ├── resolution > │       │   ├── scale > │       │   ├── scope > │       │   ├── status > │       │   ├── tolerance > │       │   ├── type > │       │   └── unit > │       └── mode > > > Is this a valid way to handle MB_MAX hard limit (and future more configurations per control)? It is possible but it does look very complicated to me when compared to using the control name to express relationship between control and configuration. Reinette