From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.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 B0CA0175A9D for ; Thu, 4 Jun 2026 17:38:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780594693; cv=none; b=otPvVmr4iwVeJMTG+zXP10QwLnqkYJIS3uECxqg7mHoD/ndCNeOjhcly+s1Bgc5Laon8PZEgGQTNOaqD3uFM0Cb6g3dijYx9d+hyiffC3PMZ7WtRypD+bZURlC/73QnYDgxQuEbdp0uPnDQtKFnOEFGQHk5vD5hX4JTcdlBBrus= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780594693; c=relaxed/simple; bh=Ufd/pJlhGe/r49YrWxypVCqY+r9OjmD2+6eghJq92Zg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nEo2CCgHbdeAsaItjNTidE2lc9nPegoQk8wQ9Yn2pI1MYoAVxWqMSi5AzoJbjW/IvmvBmdegeilHf3Qs2palnuT5qcaWHmOmNCfbfn8zxDUNB8lZD/APE2e1XqBL/y3L6OG1EaGKYDHzn+2fqAjqDg64VszZuEykO46ni8yxm+8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YJebp0ZP; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YJebp0ZP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28CC81F00893; Thu, 4 Jun 2026 17:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780594692; bh=q4sz9wdq85s26UWGOi5LNKZSRm/kx3/ztDdbzzmzp8g=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=YJebp0ZPh2g6RFeNXbdMq+49wIHEF4c6hh1MI4ZjV+rwwkN/GuD+uzH6GJpMP6YQj m6+twUzGaa5ykp+6NS0nG81o5HY3LxPWDanynpbxMkIvYEUleiasZNkTG2HolapRzM G/lAW03NFFgVFv+vc41ibB63Ua3UXqNuZfNwYEQMNa8ouDpBrHMps++iwuL6OMOju2 MpALo2+Co7lxXici+m2qAbQzMqQBpj8h9ljTHChrLGAgTUO0q73/nXzAgKxA41LriE MY3GFzCvsT5xP7lc8Cg6uViDO4E62dAIq7aJ90e/qMmW6HfcBd4isU+ofHETkxceGy qx4NUvUqBg4Og== Date: Thu, 4 Jun 2026 10:38:10 -0700 From: Drew Fustini To: Ben Horgan Cc: Reinette Chatre , 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" Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept Message-ID: References: <29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com> <2cc4d5c3-22b6-4701-b5bc-90ce4179a9c2@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2cc4d5c3-22b6-4701-b5bc-90ce4179a9c2@arm.com> On Thu, Jun 04, 2026 at 12:24:57PM +0100, Ben Horgan wrote: > > 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. > > Yes, I hope so. There a few differences which would have to be considered. > > MPAM doesn't have a concept of only applying the weights once reserved min > bandwidth is consumed. The interaction with min bandwidth is currently > unspecified. I don't think there are any designs where proportional bandwidth > and min b/w are on the same component and so it's only a theoretical/future problem. > > For MPAM proportional stride, the higher the stride the lower the weight. We'll > have to make sure that whatever user configuration scale we provide works well > for both. If two PARTIDs have stride 2x and a third x then the 2 PARTIDS with > stride 2x together get the same bandidth as the third. Whereas, to get the same > in RISC-V the two partid would have weight y and the third 2y. Thanks for explaining. I had been thinking it would be best to try to share a control for stride and weight, but now I am wondering if those should just be considered separate controls. It seems like they are similar enough to be able to convert to a common scale but maybe that would be too confusing for the user. I guess it is a matter of how much userspace needs or wants to be aware of the difference between systems with MPAM and CBQRI. Alternatively, it just occurred to me that Mweight could be mapped to MB. I think Mweight could be thought of in the context of throttling: all groups start with the max of 255 which can be represented as 100%. > It's not specified for MPAM exactly what happens when you disable proportional > stride for a given PARTID. > > The MPAM proportional control is work-conserving (the table in B.b RWKZBJ has > been confirmed as a spec mistake) and only corresponds to the current contenders > for bandwidth. From my reading of the CBQRI spec this is the same for RISC-V. Yes, I think they are the same. The only exception is that Mweight of 0 means no shared badwidth and that the group is restricted to just its reserved bandwidth blocks (e.g. MB_MIN). Thanks, Drew