From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.20]) (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 9C7B234D3B0 for ; Thu, 4 Jun 2026 21:05:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.20 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780607120; cv=fail; b=XcG/Dv+i+mNlBwU8UAhZne3eAJqnwrRerBiF7pBXMMl0i6Iwr1YfnUzuCZ/deSZFoLKEb6Hidz1tti9t7gE/Tk2XDcOYKuYq1Pudh6QRshdOj5PWjkoXZV/j62oA2OkeYQ+KNwGL7rrdemKK7hMm6+fvmkXrjUbV6m+RrjMbuwA= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780607120; c=relaxed/simple; bh=Ogr0akT0fqpx3njOR0epYrrDtrNiq08qhNOm2RBdqPc=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=AC6nzr9ZeeN/xnFSdVztFCT6Fno+HrPMzw0WBOgQBmV5YiNaDLgBXxgzdwRWK0LwEiJwd5uXq+NH21Wu6QUbybGRfCRyjxcZ2iIXqeMvJkowfh0Rr1fhU+/N+zHBKT7EWGqzl5DRnqaIHfNaTFwdQHtreSy/DtnzUKKycwaUZKY= 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=e9HwN8eb; arc=fail smtp.client-ip=198.175.65.20 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="e9HwN8eb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780607118; x=1812143118; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=Ogr0akT0fqpx3njOR0epYrrDtrNiq08qhNOm2RBdqPc=; b=e9HwN8ebws7ceII3qoG3M6xofCsI9a8FjDWPjDAdvS8vApoeHBdIiDT5 jgmRgTaGboYV2Q6eMClosSESFZndyPsHuL2XUAL9S10xGQMr4N6Nv/14V Htxw9rxmJ4AEwLUUfkDbeMojrBxURx04N8/FtzPScEu4YSSA1rBJ/Fh8a OeMuwuGLpiluQMCgHfk4rsnKLgT3vWr7+SujH5cBgT3/ETZ1A2h/dVWZf dnPE71UEnkQ7RMdb51MUxiNA3vHobwwj5c9eb7oGcP416PzwfKDTid6HH WZklV88AeBKB6wznLEOEJJ0teKcUAdd4qpj95mG4DHpEGWPcaDNVTe6FG w==; X-CSE-ConnectionGUID: 9Oky5aEpQ/+i+su4plTBdQ== X-CSE-MsgGUID: 4Gfq5kUBRiWvC67+7SGplA== X-IronPort-AV: E=McAfee;i="6800,10657,11807"; a="81187675" X-IronPort-AV: E=Sophos;i="6.24,187,1774335600"; d="scan'208";a="81187675" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa112.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 14:05:17 -0700 X-CSE-ConnectionGUID: giSqBoIGRn+pmKmM/un3sg== X-CSE-MsgGUID: 9BSIaYfGQk+VsaZEKPCZRA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,187,1774335600"; d="scan'208";a="274906388" Received: from orsmsx903.amr.corp.intel.com ([10.22.229.25]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2026 14:05:18 -0700 Received: from ORSMSX901.amr.corp.intel.com (10.22.229.23) 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; Thu, 4 Jun 2026 14:05:17 -0700 Received: from ORSEDG902.ED.cps.intel.com (10.7.248.12) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Thu, 4 Jun 2026 14:05:17 -0700 Received: from DM5PR21CU001.outbound.protection.outlook.com (52.101.62.16) 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; Thu, 4 Jun 2026 14:05:16 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LP5qXAtJm0Hrlj+agrv1ttunkt2hYyHadJSHmPAWfM4+7u5fm2t67v1kHP7oj93OvykOa3/WyECMgAQgnJ+cbcXZc3aZ7+m6TbHABOi+wpfGIn1RDnwVRmgJNzjmesPXTHMvuCIwkyiGP4PKYV18WBsky8Hm2qFf2PKrQhRZ6ikuk23gpNJOud20XMuq0FgY/U+2N2If+oDyYmMK9QCiaGumwgdSOLvf/oPrhnEoJ/ui4PgQnprj5P9P+bMpCJQsVTQS0kZjIN7TYLKVu+d5+wncPTjNpPq0hGXJGyhXlHLabsIsAXP3/HMJJLB99XpAS1jHZ8wlfFlPSsL/KcWzHw== 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=Dn4RZmEm0RTOqkOWXkbxh3sUe6cMoTWbe2RoA7ACqdw=; b=Gegcdww/JjzbWBJHhmN0P1MZ6irQff5E9Ma8G3RZp3oc7I01RVqrST9489XVTMq4NzQAWvQErDCZBPInyjLpeEIXVGnqmbgX+D5QBpdbk441S8SWrxL74c0JfbqXx8cdf/rSUgRkigEMQ25HuFJlupW2GiQXeXeIw8gP9TdAxaZKCqxA+kvCRTPjDBX5wEpqnxZ3zFJw7zAp781/wN8ILblvql+bjErWnH6DlCs6dWGpw5lw5WY5e5kzGv2DgORLt85M8vnBFgWchaXglj78fEUZuay+fob/T4HfnPRwv6CJHZ8uKWXEikZI6uSrEaybGG8iCgl4lm/JtB/cY5KIdQ== 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 LV8PR11MB8486.namprd11.prod.outlook.com (2603:10b6:408:1e8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.7; Thu, 4 Jun 2026 21:05:11 +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.006; Thu, 4 Jun 2026 21:05:11 +0000 Message-ID: <5e575bc2-e67f-4696-9332-33c54023c057@intel.com> Date: Thu, 4 Jun 2026 14:05:08 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept To: Drew Fustini , Ben Horgan CC: Tony Luck , James Morse , "Dave Martin" , Babu Moger , Fenghua Yu , Chen Yu , Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: <29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com> Content-Language: en-US From: Reinette Chatre In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MW3PR06CA0028.namprd06.prod.outlook.com (2603:10b6:303:2a::33) 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_|LV8PR11MB8486:EE_ X-MS-Office365-Filtering-Correlation-Id: f48992da-b683-42db-1428-08dec27cf6e3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7416014|3023799007|22082099003|18002099003|6133799003|11063799006|4143699003|56012099006; X-Microsoft-Antispam-Message-Info: i+468I8w7yDhZjw3Ueys0NrHHj5wCOCbuwK5IDGA79H987ZWep2ImntYhque/5ITao7qSTXw3egwd2ydhEIjSNReTcjWyV8wKW8s4wDxp/PdgqMRAKTSB8JVlpMvXxpG4H1/GRCVFLM3mr03pvbi80fsj0dxnN3GBsHNMC1FrQT5RZC3HPwY9Fm3/2baRmQ+Q170tit8D+CW5bwdIqlvm3sqHgxdhGnlK7HDd4kYIMlwN4EBxIj9rHx+tiZEHakbSvCMSEjXI5ml76kY/BmmEm9F3lt6+eIAkz+6ovelu+k/eJmwuNX2Wi9LccjeRXXNiyz1PgloW/jKWujI9Xj9d9PaWr0lHke+b0SQQLe6Og9P6CUPDopWDFc40HZ3IM3ZhfBP5dwWw88SSYHK2mPSJV/6Wm+lx7wWjwmv1k5VVf5GVsXaRZQExmB+pn/bn6eTs4bD5FkIZJLbDws1PTlArgjV9s2JYVuUewPhpWm9nEfYzhSZ9lA/C/4KwebAiJ+ybPycqyHDQV9nYRUmAMc48BX9HQ7sC2y3HkcO4j0Qg1m6WHkp9Xcl4+avIr3jgzfKYop5PsnLvJBpmIg2f3dLdLWR8DZa2++3Cwigckp664fPpNLUQfR3x3wNdgXOMYh3L5E37A9ZBPv1TSTcOp5U7Q== 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)(1800799024)(376014)(7416014)(3023799007)(22082099003)(18002099003)(6133799003)(11063799006)(4143699003)(56012099006);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dXFrRWwvQ29hYWhzZDVJOFg4aHdvZ0JzOHpTV3JpMFdETkpUcytPK1E2cm9h?= =?utf-8?B?WW1keHFLZmJ2U29PWm5nUjFuZXE3V2dVa3ZzNzUxZGxuQ0ZQQTN4UXBWUnV2?= =?utf-8?B?azJLZm0xaFF2WHVrNStVL2hqYmlaallRdkN2cmZZcjI0OHlXMDVVS09lMFRE?= =?utf-8?B?TFRBYnJwMTd1a09IWmEvdzQ0Nm9TekFmOXR2anJaZndiQjZYRnZrQ2lxczA5?= =?utf-8?B?UTJWTnBIOENWSnNZcnpCUS9PTVRrdVdpbEdKd2tOZmYveGZvKzFLZVVLVlNk?= =?utf-8?B?YWhZQlczTmhmL3FhSE10S09LdHZLL0h6R2NKWENySTVUWG1PbURvd0xSQk9k?= =?utf-8?B?YVpoRTB3U1czSXJFRHlxektZMmczeGZvWFdwTTFXaVp4NkVuYjdYNzYxVTEv?= =?utf-8?B?TG1qMWN1WlN3UHhpS3pQc0F5UGhKY0xCK01RWkpjdVMrWnRmWkJoemova1hj?= =?utf-8?B?cEh6ZjBwV0FxK29hTmVpbTlJZWRTaEViWnV0QVVtOFhCRDZTenNJOU1NTHRS?= =?utf-8?B?UVFLeGFUMjEzMzIxZ1FRemprTnlpL0cxalZuZWtKME9GbGJWNzRVOXdldVRw?= =?utf-8?B?czdXWHR4c1RRMmdsdnVIWmY2MnhvUVdMSzJ0L2pXYWJmWjNBd3h6R2hXYXVH?= =?utf-8?B?VEgwbW9oMFhjM2RicmVSZTJUUjdYem9IWXFKQ3FnbWRhdjVJUWtCR05JUWV5?= =?utf-8?B?L2sxbXh2c1FSQkdZb29QSjBtNFQ4cTgrZ0hRbGMyM0NGZUxvY2RuZk5DZ3Ix?= =?utf-8?B?RkVqUEhveEhUNjI4VGlpSWwzM3dWeldGcmFaL0trbWZtSWMrRlZydmdLRzg4?= =?utf-8?B?OTgrR3hDa2hVdnc2N1pNK3YxWkVNVmZwVjdCVktpdXRtNm52dUQrT1BwY1dM?= =?utf-8?B?SE4xdWY5bko5NVN0VlhMRy9RSXNKYmpuQldSUGs3ZW8yb0tuQ3JKbzVMeGRD?= =?utf-8?B?ZHpRei9lY1JMWGxnYXlycENSZGZkSEg5aHE3b3NuRGJ2TWhRWUFVNFNYUWo2?= =?utf-8?B?SEVjMHNtVHRTQ2Nad3UvaG1sYnl1ajlyLzhLUEdydCtjMzZRQ3FXNmNvM1Zv?= =?utf-8?B?SjY0dWdtT0lpRVVyOHgvM0tKaWZnNXpiQm8wRk52OXcrcGZodGJSeHR0K21N?= =?utf-8?B?M1FOSDJSUjgzam54U1RGQjZqYjgxSGNjZ0RQWWxIY0F5ZFBUK3ZoNlhZMjhN?= =?utf-8?B?U3VpQ01HcEQyT0psbkQ1S01vL0ZvemM5bXZmcTdhMW1zSzdYNHI2ek1hTm5B?= =?utf-8?B?WFJ5bmNKSGZVOTZ2K3BNb1VXSFBwOG02OE8xTTBTZDBXQWR6OVJTQ0YwNmov?= =?utf-8?B?NzZPY3ZSQjNIYlFZVnBZSTFBcDdUU0dKWFJiRUFtRFU0QnpxYndWK1YxRUdP?= =?utf-8?B?YXJYWU5meUN4YVE2TkhFUHpSb0RMOXoyaFRSUXBneHFvSlJ1akprQkppeE1z?= =?utf-8?B?WVdhTGNNeFhseG1kNDc2WThUL0F4QWhGV1pEaTZ0ZVlINEhYOWdkTk1jVjQx?= =?utf-8?B?dmdHSnAyMFlVSElXMWRabFdpb3krQUlRbytOUXBwY0g5YmJjR0dMK3RRTFNv?= =?utf-8?B?SjhPUXpGc0t4K3EwU0kyYUk1Z2ZlZFYydHdLdTZJeUxRSWpiemRuckNsWDY4?= =?utf-8?B?NUQ3SkpBQ2JKaFJlTENMNE9pZjZvT0dzZG9yRk84Sko3dk9QN3B5TFFDaXJN?= =?utf-8?B?ayttYXZvbTFCU3hHai94MlRMa0lRYjc4U3V0aFliSWdXTnp0THZ4OWNwWjJ0?= =?utf-8?B?Uk00am13QVpQNmZWMUhiZHYrZngzNUtzbTJncGdzNmhiTjlTUy9QbCsxWTJj?= =?utf-8?B?elFkaUw2NUdZb1FUYS82bXRPZUhhUDlRQ2g3bXJRU0EwbFNaVjdXcEVNN1hU?= =?utf-8?B?clRWNm0rMXJ4VkxveCttU2paVitHTWdQcTdBUzF2SkNndFJ6Q29HUjBLS3hY?= =?utf-8?B?OEFJZ3pxREl2V2UyeUd6ME1GdE5RUllDaGN2YS9GbHdwQzdMV3dXZysxN0N1?= =?utf-8?B?aDZyeUdacWhnZXBWZ3dRMmJQQzZ4VUhSRGh1YXdHbGZ1a0Z6QUZMeHJXNHg3?= =?utf-8?B?NHJ2SmpYVW5VZTJWd2hVNjhRRksrbnBhQ0NEa1FTcFJ1YTlnd0psaFJHanJU?= =?utf-8?B?TEtJaDBza1pVTy9iRVBvclR2ajNoWVp4K0tIZ2JacDgycXNYTUtnQjVVQmtD?= =?utf-8?B?U01DMFN1ZThCQlk0RWVFRDFsUW9tMWVqSjlxcFQ3N0dTR2NJNDhxbkhLYWlT?= =?utf-8?B?VnFqQnNJMnE3SkFYeVNJU1Zid1IzMXJBaW9ZTFVyM2lSWTd4dmxjZjZLS0h4?= =?utf-8?B?aEllU2o1VUVWSUhrWVpEMy9ZZlR3QitXUjEvNHFkZjNLcUhMRjVNQjU0WWIy?= =?utf-8?Q?IUYXtJ/fW89CJOOc=3D?= X-Exchange-RoutingPolicyChecked: NlyisigmyxQvtQyPKtkVfPoirTu8l3vBVvIgyvgxrARbqhioa3qUmAmPs4e+m5rGZcVwlB8e+WyQ7PlaM0dAnchThCwmcvecpvRgEXT3q4jLqxROcdxYM5l42KoypNFO+Yh4V59b4pI5XrmcRkoSwx1KOUPjkRq0m3Dfhg+kn+a0Di+FykPxg2G2cn2skbbyubHDspV8tofNndxSMqXV7c338lMVSnWs/sxIwewwdZk6rdvr767dnuxy3yyyTxx6HttqkJuSfAX+G4ztkCsxXJ0BYeTmbugH8Tjh5Ndhriltz0UpK9TCBfcxgx6/+BR8BA1bxOBJdVqcchkUYbzufw== X-MS-Exchange-CrossTenant-Network-Message-Id: f48992da-b683-42db-1428-08dec27cf6e3 X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB8370.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2026 21:05:11.1154 (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: qzKNbFe1SkiW8DpO2fYZEdE2rjIzy3mK9t8HzbUXq/AxerRHiV3C8ShP1jN1P2L1RUKPXasQWhe3C50dqc1MCTUcQuifuaJfwmlCiocCPxI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR11MB8486 X-OriginatorOrg: intel.com Hi Drew, On 6/3/26 12:34 PM, Drew Fustini wrote: > On Wed, Jun 03, 2026 at 04:15:51PM +0100, Ben Horgan wrote: >> Hi Reinette, >> >> On 5/29/26 19:06, Reinette Chatre wrote: >>> Hi Everybody, >>> >>> It has been a while since we discussed the resctrl changes required to support >>> hardware that has controls with fine granularity or hardware that has multiple >>> controls per resource. For reference, the most recent email discussion can >>> be found at [1] with a summary of discussions in last year's plumbers slides [2]. >>> >>> I created a PoC that I believe supports what folks have agreed to so far. I >>> hope this can help us to restart the discussion with the goal that resctrl gains >>> support for upcoming hardware that require these features. >> >> Thank you very much for doing this work. I believe this will be very useful for >> MPAM and other architectures. > > Yes, thanks to Reinette for working on the generic schema proof of > concept. This will be helpful for supporting the RISC-V CBQRI (capacity > and bandwidth QoS) spec. Thank you very much for considering this work. > >> I plumbed in support for the MB_MIN resource schema which also works under light >> testing. The only fs resctrl code change I needed was: >> >> --- a/include/linux/resctrl.h >> +++ b/include/linux/resctrl.h >> @@ -483,6 +483,9 @@ static inline u32 resctrl_get_default_ctrlval(struct >> resctrl_ctrl *ctrl) >> case RESCTRL_CTRL_BITMAP: >> return BIT_MASK(ctrl->cache.cbm_len) - 1; >> case RESCTRL_CTRL_SCALAR: >> + if (ctrl->name == RESCTRL_CTRL_NAME_MIN) >> + return ctrl->membw.min_bw; >> + >> return ctrl->membw.max_bw; >> } >> >> >> At least on MPAM systems, we use a default of 0 for minimum bandwidth controls >> as the maximum bandwidth controls only take effect if their value is higher than >> the minimum bandwidth value. I have specialised this on the ctrl->name which >> breaks your ctrl->type based classification but that's fixable by just adding a >> default field to membw. > > This should be useful for RISC-V. > > RESCTRL_CTRL_NAME_MIN maps well to CBQRI Rbwb (reserved bandwidth > blocks). The sum of Rbwb across all control groups must be less than > MRBWB (maximum number of reserved bandwidth blocks). As a result, MB_MIN > needs to default to 1 so that the sum does not violate that rule. In my > RFC series, I added default_to_min to resctrl_membw [1] but this > solution looks cleaner. As I mentioned in response to Ben [2] there seems to be a mismatch between architecture requirements here. resctrl uses the value returned by resctrl_get_default_ctrlval() as the control value that means "no throttling". For Intel this means min == max but this does not seem to be the case for MPAM and CBQRI. I am not familiar enough with either to have an alternative proposal here so I need to become familiar now. There is a bit of backlog on other resctl work right now so this will take me some time to sort out. > >>> - No support for "read-modify-write" usage of schemata file. This is where we >>> discussed (without agreement) on possibly introducing the "#" prefix to schemata >>> file entries. This PoC does not support this prefix and the current assumption/expectation >>> is that when user space changes a configuration only the new control values are >>> written to schemata file. I thus do not have a plan to support this so please >>> share opinions in this regard if you have some. >> >> There is now less motivation from the MPAM side for this than when this was >> initially discussed. In pre-upstream versions of the MPAM patches a change in >> the MB resource control value would change both the mpam h/w mbw_min and mbw_max >> values but now (on non-broken h/w) we just change the mbw_max. (mbw_min kept at 0). >> >> However, it would be useful not to be limited by percentages. In my quick >> experimentation with your patches I used a percentage value for MB_MIN but it >> would be best to move away from this. For new controls I think we can mandate >> that user space has to discover the resolution from the info directly but how >> can we retrofit this. For MPAM, MB and MB_MAX, would control the same things. >> Could we just add MB_MAX with a h/w friendly scale and then reflect changes in >> MB_MAX in MB and vica versa with MB taking precedent if both are set? Old >> software can continue setting MB can move to using MB_MAX and take advantage of >> the improved control. (I don't think we should expose the MPAM hardware value >> directly as it has confusion over whether all 1s is 100% or not and we'd like to >> have something generic and friendly to the user.) > > The facility for non-percentage value is import for RISC-V as CBQRI does > not include percentage throttle. It has two controls for bandwidth: > > - Rbwb: number of reserved bandwidth blocks [1, 2^13] > - Mweight: weighted share of the remaining bandwidth [0, 255] > - 0: disables work-conserving sharing > - 1..255: compete for the leftover pool > - It makes for it to default to max (255) so that there won't be > any unused bandwidth > > I think Mweight could be aligned with MPAM's proportional stride. > > Here is the patch I created to add Mweight support: > > diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c > index d95ab8ad36e2..3537071e3ab0 100644 > --- a/fs/resctrl/ctrlmondata.c > +++ b/fs/resctrl/ctrlmondata.c > @@ -304,6 +304,7 @@ static const char * const resctrl_ctrl_name[] = { > [RESCTRL_CTRL_NAME_DEF] = "", > [RESCTRL_CTRL_NAME_MIN] = "MIN", > [RESCTRL_CTRL_NAME_MAX] = "MAX", > + [RESCTRL_CTRL_NAME_WGHT] = "WGHT", > }; > > const char *resctrl_ctrl_name_str(enum resctrl_ctrl_name name) > diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h > index 72fb7256270e..09efcef9ce66 100644 > --- a/include/linux/resctrl.h > +++ b/include/linux/resctrl.h > @@ -348,12 +348,14 @@ struct resctrl_mon { > * has the same name as the resource. > * @RESCTRL_CTRL_NAME_MIN: "MIN" > * @RESCTRL_CTRL_NAME_MAX: "MAX" > + * @RESCTRL_CTRL_NAME_WGHT: "WGHT" > */ > enum resctrl_ctrl_name { > RESCTRL_CTRL_NAME_DEF, > RESCTRL_CTRL_NAME_MIN, > RESCTRL_CTRL_NAME_MAX, > - RESCTRL_CTRL_NAME_LAST = RESCTRL_CTRL_NAME_MAX > + RESCTRL_CTRL_NAME_WGHT, > + RESCTRL_CTRL_NAME_LAST = RESCTRL_CTRL_NAME_WGHT > }; > >>> - Controls are independent for now. This means that, for example, if a resource >>> supports a "MIN" and "MAX" control then this implementation would allow user to >>> set the "maximum" control values to be less than the "minimum" control values. >> >> I think this is ok as long as adding support for new controls in resctrl doesn't >> change the existing behaviour. In MPAM we dodged this by introducing MB as only >> affecting the h/w mbw_max and not mbw_min (as mentioned above). > > There is no equivalent to MB (percentage throttle) in RISC-V so I would > want it to be valid to have MB_MIN (minimum reservation) without MB. > > I rebased my RISC-V CBQRI v6 series on top of this proof of concept and > was able to validate it works okay in Qemu: > > MB_WGHT:72=255 > MB_MIN:72=756 > L2:64=fff;65=fff > L3:75=ffff Ideally any new support should not break existing user space and the existing user interface expects a MB entry in the schemata file when the MB resource exists. Is it possible to emulate the percentage based MB control with MB_WGHT or MB_MIN? This sounds similar as what is/was planned for MPAM [2]. Something that may be of interest is a proposal that Chenyu is refining to address an issue with the region-aware MBA support where there is no intuitive backward compatible interface. This was highlighted in the plumbers slides (see slide titled "Open: maintaining backward compatibility when region aware"). The current idea to deal with this is to introduce a "mode" associated with the resource controls. For example, # cat /sys/fs/resctrl/info/MB/resource_schemata/mode [legacy] native By default the "legacy" mode will be enabled and exposes the "MB" default control to user space via the schemata file. In support of this each new control has a new property file named "status" that can have value "enabled" or "disabled". Only "enabled" controls are present in the schemata file but all controls are always present in the resource_schemata directory. By writing to the "mode" file user space acknowledges familiarity with the new "resource_schemata" based interface and can change the status of a control and thus manage its visibility in the schemata file. Could something like this work for CBQRI? Reinette > [1] https://lore.kernel.org/all/20260601-ssqosid-cbqri-rqsc-v7-0-v6-6-baf00f50028a@kernel.org/ [2] https://lore.kernel.org/lkml/c78169bc-e2d6-4583-96ec-09fa6dd6653a@intel.com/