From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 70D9741D138 for ; Thu, 23 Jul 2026 23:31:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=192.198.163.18 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784849508; cv=fail; b=baL4uKjHA8INHOV7QAwwVkIyy1YNXjPE/YzElF6ProdwEE2Gf59PKx2zcb3mTH/4q7/nt69DZDzeK0dMivngp18kyxnJmdBZEdsiVdJhbYTFwqiC71TcpdTKvaOWN+53ywOHuVO/fYodyf+DGpEnEGve+Kes0FGM1yHn9amgLxM= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784849508; c=relaxed/simple; bh=6WrhcSvn8oAFYGkT4udGogtmnm7NyxcxTnOdLlcS7Yg=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=MUWW4wbY6KVUUC7L8VtZmVVsCLVV6kH/Ho2ZYHpuGxW9cMdZlcSKxTiTvLXQwxCkw04HKVvPdwTGRcRnq4eqfGFCPV9GupgIA56ECUiXRDgJZwWfK4zZhufx0om8Tg0UUoqqdKAEHqJnXt28rNT1FPkKP4X9XzgNIEr8tphR93g= 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=E2CteWo2; arc=fail smtp.client-ip=192.198.163.18 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="E2CteWo2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784849504; x=1816385504; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=6WrhcSvn8oAFYGkT4udGogtmnm7NyxcxTnOdLlcS7Yg=; b=E2CteWo2kxUpDXmBgi7yyqRo3fXpSHSgU0YXjOZcReik8i5cdG7bYZLq BsmhntiaccDXbjStB7sYR4h4dYab0wSAUEoddvLVekplCgsM2VFBGg2KM 3UN+aw5sTxWOifKMlQB48B5r2TZeAZpsWeqAw1PP8ILKJlKJgQPvxMTy3 piFBSSQ5p+9luuop6RV01dAG5IPvwwy6lKg8kVHsK2nZLFF8Ej0mVlimh rGDYVfs6FxpR3ENtMXpyVRceQWsg8m+Bq5y3cM74wqRZMirnMmzf2jfZm bTxvMkDXlKUqZbI1iy0sWMD0zwtBU2rcSrXmMQs7zb/t+sbq1AEK0dCq0 A==; X-CSE-ConnectionGUID: Nu4k9/KvSqmej/uMk2lRng== X-CSE-MsgGUID: fAHURibiRuCswou/1z5YVw== X-IronPort-AV: E=McAfee;i="6800,10657,11854"; a="84642437" X-IronPort-AV: E=Sophos;i="6.25,181,1779174000"; d="scan'208";a="84642437" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2026 16:31:42 -0700 X-CSE-ConnectionGUID: LSchGDenRly6eh+RnLGy3w== X-CSE-MsgGUID: xmKXhM1SQuy+LkL02hecKg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,181,1779174000"; d="scan'208";a="262864803" Received: from fmsmsx901.amr.corp.intel.com ([10.18.126.90]) by orviesa005.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2026 16:31:42 -0700 Received: from FMSMSX902.amr.corp.intel.com (10.18.126.91) 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 16:31:41 -0700 Received: from fmsedg902.ED.cps.intel.com (10.1.192.144) 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 via Frontend Transport; Thu, 23 Jul 2026 16:31:41 -0700 Received: from PH7PR06CU001.outbound.protection.outlook.com (52.101.201.45) by edgegateway.intel.com (192.55.55.82) 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 16:31:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=a7dQ+yq+KAVcUXbXsS0XjbneVlF1Hhsd3QOiybGtzJUQjeKji4FgshSlBBk+ZnFs0R8sPZpd99h/QYiN84XxE3jQn43SL7KYATPeprXn27RvWNX01aG79uORY6ncq/B4egDUvvHqCciOv9+laGP/1eqDmW3CeW8hmDCtE6eqJwWVJn45xo8J322h83BUiMoBmbT33U55qbiB1NgncFI5F/CfNeFHnPVmgpRGkjNiA9L2/eWdciNw7aHtccVArThTILsvWQ80DoaRXPW4qKJpvKrO4r1Lz/eA1jUJnCfheiN4fNkKd8lxCynMeNRNdCFrZamVeSYDj2SJzPKiHN9dKA== 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=AUojtms5nemCp3zx8+MmCkydQHHARm727NSE7LG0D6w=; b=hfDYiCZei6OFVbM5MEHTX/hehWLMq0ej0an2jue5GrIVz40spg6NBpFrmQHHVcnftK4MkXXLsvR2vz1NCwylV9pt+qaWwRkkbk3rQbYrWTga7tuDWW30vSA/zDpUQrnfhYhEHiGzK4PtbQXAQJ15p8lm1dXfU02RTaC4W5LLskFbjlcC1o3ef9DMtla1N1z0ObDOKHMJqQHNMAktONuPBeeM4jBrdW6e4oxENduL4owmPKnbZ2gi7rz9ldBSrDcuHRbvxkSHK001mdZ7zksUGx4Sa6aHyBHSLdr+qu3kxRN6NBGQsszwLxegHC3bcK7gbhWTiRTJFN1CBQ3r27EwOA== 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 MW3PR11MB4698.namprd11.prod.outlook.com (2603:10b6:303:5a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.245.10; Thu, 23 Jul 2026 23:31:31 +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 23:31:31 +0000 Message-ID: Date: Thu, 23 Jul 2026 16:31:29 -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> <917ef5ed-c720-4afe-aee6-3ec201e565e0@intel.com> From: Reinette Chatre Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: MW4PR03CA0182.namprd03.prod.outlook.com (2603:10b6:303:b8::7) 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_|MW3PR11MB4698:EE_ X-MS-Office365-Filtering-Correlation-Id: 0b2494b4-3b58-4423-d1af-08dee91286dc X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|376014|7416014|23010399003|1800799024|3023799007|6133799003|10067099003|56012099006|11063799006|4143699003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: fg+IQlUAr8KBWpZ6CUiGIK3zHl0FIT78EA4Pg6tvYThWwacvX4OGLZu6s7UZY5Jju/XNGp6T0XAjSrd3DGgr/GwzDrnDDnoR0Yu3NIs3bPj0gwHgcklXrIddeGUCV1gmhUANW1eRRgXGBXAaJX8zkggXUQPws/ZWHFwHh3nN0CQ/iu0RJK0JnpdvpFfd8u6ogHveKnT4M08wfCrLYUgk8FEVvixQNejo78RWH+qdn5ZQQoB3IYsDYlz+r4iK8HHuYjBvqF683NKZ8qZBVfdqB6LWJnNtkD+lUUdLcm0mnCw8zD8x4+TH35ZAZtFAJSRbCl5EnI/siv2+59KjFWFAc2YfS5qOwIlKlLp1of5hUd7RUZwexQyjrLc/lWQsYtP74IartbrQayGqAORfK/p072j4B+eU5bYh6zoyq3QH7xw3mI0QILLDViXYQoG2vB7Kz/cMQ8MERFFvP9qG1KMaF2xzqlcZwk1Yz+geMlT46D42xCDu/+BMdufap3FefWB6b2aO1t6CIR0qxk2OBSbkl219VhvdzLO6Wzk4uOuapyH/M+8cxaaKJwMZ2AAMecFDq2zcNahJjd06vyTHflDL2aPk357wkdM6TM9EFMrVpQ9V0TPY9RKlkLnuLDKJrhr7PoLuxLfcJdd/6Lagtr63jvsN+O4QXUpQfepUMeLF8cU= 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)(366016)(376014)(7416014)(23010399003)(1800799024)(3023799007)(6133799003)(10067099003)(56012099006)(11063799006)(4143699003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UktCVnRSWVNDZEs2SUd3NHVsR1ZBdmZmMTh3UHVOUVJmQ20vZGtyTEZyQ1l6?= =?utf-8?B?b2tVZ0R0bkV1aFFGcElvbW14aGdhWVIxZXZsM1AwTnROK2Y2KzNxaWN5ZG1V?= =?utf-8?B?anFlV2tjWjNMcllvSUo4NG85M1AzdnlZK1hCWVJBd05rYXJkVFVRSFkvM3lq?= =?utf-8?B?ZWpaei83RHMrdU00ZGhZVE9RWVBFTEthWWtKSlpxNElaRk5HdWxtbk9aRXFn?= =?utf-8?B?MTdUZW5tQnZ6YnFZNEkwam1ycFBGRk5YSHErbG44K1I2bmM3ZzVvL1I0b3hZ?= =?utf-8?B?NFZUeS9mUXEzNFhHb09uT2IyQlhOc2xncmVrSUNZQnpDR3ZucWdWV1Z0QUdK?= =?utf-8?B?VVFxRnNOaGkyYndqTnN5WmNEblE3bHN1VmJFZmpPQThHVVZRZUk0bkxaam5n?= =?utf-8?B?SkJ5Vldvc3hYSUU3Z0l3UlE5YmU1SXNxSlQveTZUZG05TmFmeURyWkdwSUxE?= =?utf-8?B?ajNMV1BQcVk4SWZFSC9tck9LM242R0RYcG1ESW01cDVqVE9oMjFLZ0J0Z0Y4?= =?utf-8?B?SlhLeUU2K1ZzYXBzem1EcHpEOTgzMGNRUWdOVWZ4TXVpQTkxWWsvSktVTzVl?= =?utf-8?B?dTN4ZHo3RUIrKzhxZXNGSXV5SHlxVVp0YkRndWNnQUY4Zk9pK0E4YjJNOElF?= =?utf-8?B?M2JnUUpQMjZJekJZNVU0ajZ2RUZ5eWJGUFQ2cDY1V0YrQmlpYjd2V0pIaU1I?= =?utf-8?B?S3NUZ1lvUFpLVnMrdDdqU0pPeTdwN3drTE9iWXlKV1daaXZJbGdDTjJsUjZU?= =?utf-8?B?VlVuZXpuOFJYaWhzTVVuakJrNlNVLy9PVENIYUUvNDQ1VWxoeUJTcExpUXFp?= =?utf-8?B?WnM5UDdzN29yNnViN2VZYmk2L2lCN2Rnck5BU21FMDZEOWNtdWdGNmpLYlUv?= =?utf-8?B?VkpZSVVFYnI5SHp3VlJ1blVOT3daemRLcld0Wi9XTjcrZlA1cUM5YmlnNmFB?= =?utf-8?B?T1JFWU9nOXBCUUF5ZmU0dDdwV2kwSkZMRmNEMmZXdmdBK2xxRWpubUJ0WjNP?= =?utf-8?B?MGNNVXNJajFyZ3hFbHk4c0N1Z3hTcFdvTkIyeHZDODJVOE1BR01qRkxaZVY0?= =?utf-8?B?dS9zRHVhY3JIQ1ZLdTlTS3FJRWVoUk1wU2pkWEZIbDVOVXZKaXdhMkYzVWJo?= =?utf-8?B?M1pNZUkxRzNTNzc5OG1QUmtpUTlsRmJRcGtGUE51UVVLclBXUWw5TmdhaXhx?= =?utf-8?B?a3lmMWpSeE85QXU3WjZBckt0WVpJVTBNVFBZSEhyQkFXUWlpQkFVSjhqb08v?= =?utf-8?B?Z2dRak83RFZTV0ozdTA4amo3ckdBL211aW5jaDRJVEV4ekN0V2tRWHpLMVFs?= =?utf-8?B?MUszS2p2TFczNXIzV21la2VuQzRVZzNTckxUNGphenlsNm55REhnNU5GYVp2?= =?utf-8?B?Um9EU2g4Yk4wY0ZrZktKTTZoVGhDTEtLdWo0NmhtRmlZcmg4YXB0bStva1N3?= =?utf-8?B?eWxTNGRDd094Q0thSC9ndnNyaUo5ay9JcEJxTzlyNWh4TGpqRVh0bS9KUlJ4?= =?utf-8?B?RG1OeUdOaGIrVGtjNkhEdStadEV5NzBoRkdsKzgxejk4amVnMFRRMURLZ0Iy?= =?utf-8?B?NmpySStuTER4WmZMcWM0S2FPdkNiL0l5b2ZUamFSOVhtY3h3cHBXbVNZOENt?= =?utf-8?B?TEZyWHFncUFhRWY4Q201aG91UWdiU3dhcG5FTlFMVUdEdklHMDUraUN2Yzlj?= =?utf-8?B?YlJUT0dSdkJlTnV0MzhPdmxPWi9XTStCNWp5N0ZJdFpPR0RsTXFFMkRjMFF5?= =?utf-8?B?WHE5NnVsVjdxOVlvTldVNmJJOUdSMVlabjg3NEEydFk5MkNpQ1Y3dy96NnRk?= =?utf-8?B?elBUNFhMUG5aY2RBTFVYNmdLbnlXTnQvbmNOckxWWXFsRnJiWW1OdVVDSzhY?= =?utf-8?B?cDdxZHFKbExmaDZtRWtGK0ZzcUhIb3Q4MUdwd1dWakNHSWUxaTZ1LzRPYnJR?= =?utf-8?B?V3JHK3U0RUR5R25uOWoxR09OeWtlV2Y1UGRMYU55VDdLdnZrQ3l5b1piSENt?= =?utf-8?B?Y0FabnV3SkNCbGRKMnB1cFpCaFZQYW1OdW43TmZxUGlIeWNRTEtwY1orc2tN?= =?utf-8?B?MEMvbzRHNW56eW5nbExuWFZ1YXNJb2hoSVl4VEQ1RFprbmNab1YwbzY5cjA3?= =?utf-8?B?NjhDcStFeGZWbzRRU1pkL0pBTUVwdjNVaytkK0FEdDQ0dWZNUEtRRzYwd3Zn?= =?utf-8?B?NVZTQzlnemk1YWUxb3pOWWQ3SUpERkZnS0tLdkhyZXNOODY5MVRBRHNMc1lL?= =?utf-8?B?SXYrTHBRR2RET1JXcEVZWG1Jc3hNYUpHaHZuNHd6Yks1ZmtrakpsNWlPNE02?= =?utf-8?B?d0lqNEZoajRrcjY0djVoNHRsTnFiUkpkWHNIb05Kazc2ek5sc2J4T1d2Y3Zm?= =?utf-8?Q?tgpiVqGSGQ1aoFts=3D?= X-Exchange-RoutingPolicyChecked: ieuDS0BxvEU+OmOXgRIoNoOFQRsXo47GCOyPjj0ujt4/QLeozqEdmrN3zDMhfg2/FgFid7p5P8DbQqjiWHo/uEPqC6FJyYLrQYr/9UW+iwG6R0M9LjWbS1R4j+KIN4rkeLwMntnuzzVk5EP0X8S4iFFE95AESTfDxPjJiyuuctTsWlih5dDEcv/Vk15pybnNNtE/Le3el/BgMsO5x1lKcjnbe1gcyiCp3cGUaTssvcx3LI6xKQMxTiCVhe7Tui1jgqQSnr58uE/ONoCXU9FPwicATldqjzJ1LWJDUIbDzXlM5CwIreEqzk7uMG8/Vfqdrhsy0MCxykdLKZgbTCDQ0g== X-MS-Exchange-CrossTenant-Network-Message-Id: 0b2494b4-3b58-4423-d1af-08dee91286dc X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2026 23:31:31.6467 (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: WiFoeI7xFGI7QiRtLVoJJ3znwY5KP6jg2IaWHV6y8f1uH/YxmCRRCpcwk2y9nU1eqf82CFLSSU0zfUduQ7lYZAf9ELmlh3ZK8m/iEAPkjng= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4698 X-OriginatorOrg: intel.com Hi Fenghua, On 7/23/26 3:27 PM, Fenghua Yu wrote: > On 7/23/26 09:18, Reinette Chatre wrote: >> 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/ > > Yes, I had some input in the thread. > >> >> >>> >>> 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? > > Yes, it's a list. A control may have a few configurations. Currently > there is only MB_MAXHLIM configuration in the list in MB control. A > list may be expanded to future multiple configurations in one > control. My question was actually what the list members would look like. This is not clear from your proposal. I expect them to, in turn, be another list of struct resctrl_ctrl. This list thus introduces an additional layer of abstraction that I do not currently see the need for. >> 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) > > Yes, add the name HARDLIM is fine too. > > But the arguments for adding this configurations in a control are: > > A "configurations" is different from a "control" in that: > 1. The configuration configures the control, e.g. toggle hard limit on > MB control. I think it can be argued that "hard limit" is a control since a "control" is something exposed to user via schemata file that is used by user space to control how a resource is allocated. > 2. The configuration doesn't have the control's properties (e.g. gran). This is because "hard limit" is not a control of scalar type. "hard limit" is a boolean control that still needs to be introduced to resctrl. I am in process of refining the PoC based on feedback so far and adjusted the struct resctrl_ctrl naming that I hope will make this clear. struct resctrl_ctrl needs to be changed to support "hard limit". Currently struct resctrl_ctrl looks like: 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; union { struct resctrl_ctrl_bitmap bitmap; struct resctrl_ctrl_scalar scalar; }; }; To support "hard limit" resctrl needs changes like: diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h index 6ca7474680b7..6eb7ce831830 100644 --- a/include/linux/resctrl.h +++ b/include/linux/resctrl.h @@ -323,6 +323,10 @@ struct resctrl_ctrl_scalar { u32 reset_val; }; +struct resctrl_ctrl_boolean { + /* to be completed */ +}; + enum resctrl_scope { RESCTRL_L2_CACHE = 2, RESCTRL_L3_CACHE = 3, @@ -334,6 +338,7 @@ enum resctrl_scope { * enum resctrl_ctrl_type - The control type * @RESCTRL_CTRL_BITMAP: The control is a bitmap in hex. * @RESCTRL_CTRL_SCALAR: The control is a decimal number. + * @RESCTRL_CTRL_BOOLEAN: The control is a boolean. * * Used in struct resctrl_ctrl to identify the member struct that contains the * properties of the control. @@ -345,6 +350,7 @@ enum resctrl_scope { enum resctrl_ctrl_type { RESCTRL_CTRL_BITMAP, RESCTRL_CTRL_SCALAR, + RESCTRL_CTRL_BOOLEAN, }; /** @@ -400,6 +406,7 @@ enum resctrl_ctrl_name { * @bitmap: Bitmap control properties. Used by cache allocation. * @scalar: Scalar control properties. Valid when @type == RESCTRL_CTRL_SCALAR. * Used by memory bandwidth allocation. + * @boolean: Boolean control properties. Valid when @type == RESCTRL_CTRL_BOOLEAN. */ struct resctrl_ctrl { struct list_head entry; @@ -410,6 +417,7 @@ struct resctrl_ctrl { union { struct resctrl_ctrl_bitmap bitmap; struct resctrl_ctrl_scalar scalar; + struct resctrl_ctrl_boolean boolean; }; }; > 3. The configuration is similar to "event_configs" in MB_MON, that can > also configure MB_MON's event_filter. I am not able to see this connection. event configurations enable global configuration of how monitoring events behave (what they monitor). Attempting to map this to controls looks to me as mapping them to the foundation of the new schema descriptions where control properties could theoretically (not supported today) be writable and not as today just read-only. Mapping to event configurations would have the "configuration" changes to control impact all resource groups. > So distinguish "configuration" and "control" might be more hierarchy? Adding the config name in control name doesn't show the hierarchy of the MB and its configs? The hierarchy is indeed shown in the control name when the control name is ___, no? >> 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. > > This configuration is similar to "event_configs" in "MB_MON": > └── MB_MON >     ├── available_mbm_cntrs >     ├── event_configs >     │   └── mbm_total_bytes >     │       └── event_filter >     ├── mbm_assign_mode >     ├── mbm_assign_on_mkdir >     ├── mon_features >     ├── num_mbm_cntrs >     └── num_rmids > > So it's not a brand new info hierarchy. Both of configs change a resource contorl/monitor. It's just for "MB" not for "MB_MON". > > What do you think? I see what you display as what we agreed on so far with the foundational "resource_schemata" or "schemata" directory mapping to "event_configs", the subdirectories (like "mbm_total_bytes") mapping to the controls and "event_filter" being the only property that in this feature can be writable. Reinette