From nobody Fri Sep 25 13:55:23 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 24BAC44604E; Fri, 11 Sep 2026 16:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789144589; cv=none; b=TITPtPBiy0fB7slFfDcFQQ6bGjS+0XAyRirGMpmfFJ6Ekinlhy4ze5gpgFaAxD9GNycQIwjh8UN1CGxRz3VYoan9epC0ReeSeU01qx9szB4DXuUzW9j/rKO3q0VkoUwXCypfm6c4gypLLuFSQBfghjYonifX0vym/RXZumIf/RE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789144589; c=relaxed/simple; bh=837kUJ2DyBJdMsn+nQT0dd7XZOMmGqzBv2yaOYUE7uA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=plGttsEfJ5sjRy9PX19FQ7Q6NjwcPDd1umg98NHqTrLzcn2qGTlXbXdt0eL4EL8teg41BqwiTq1WUgq0jIxOL6770n4Wh+vTy3yqUzYz8EP7e6Fb3BgCME8sDdcnEEiqjn58Hr9N0GHA8D+qcZLQYeyFBLHWMwg8rrWrO/uLV7A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=b6V1RQ9w; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="b6V1RQ9w" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D60EE2BC4; Fri, 11 Sep 2026 09:36:22 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C270E3F7B4; Fri, 11 Sep 2026 09:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1789144586; bh=837kUJ2DyBJdMsn+nQT0dd7XZOMmGqzBv2yaOYUE7uA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=b6V1RQ9wo9ljg176S810jYUqivES+ifCOupiE7XDB7I3hVEFWaB1Tgp37UWxrH+fA dNFL/GTEtQsC7sMzpPYWzAoumQsGssDncEqIg9BQmvgqaouC04o18bUEJud2PHau06 SNBMKxi4gLf3u5P2ZyY3XoegjNe3x/DI5WG28RuU= From: Ben Horgan To: ben.horgan@arm.com Cc: james.morse@arm.com, reinette.chatre@intel.com, fenghuay@nvidia.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, corbet@lwn.net, x86@kernel.org, linux-doc@vger.kernel.org, dave.martin@arm.com Subject: [PATCH v6 1/3] x86,fs/resctrl: Add resctrl_arch_preconvert_bw() Date: Fri, 11 Sep 2026 17:36:11 +0100 Message-ID: <20260911163613.1131447-2-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911163613.1131447-1-ben.horgan@arm.com> References: <20260911163613.1131447-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dave Martin On MPAM systems the rounding behaviour of the MBA control would be improved if the rounding in the fs/resctrl code is removed but this is not the case for x86. To allow any rounding or conversion of the bandwidth value provided by the user to be specified by the arch code a new arch hook is required. Introduce resctrl_arch_preconvert_bw(), and add its x86 implementation. This is currently unused in resctrl but when plumbed in it will replace the call to roundup() in bw_validate(). Signed-off-by: Dave Martin Signed-off-by: Ben Horgan Reviewed-by: Reinette Chatre Reviewed-by: Gavin Shan --- Changes since Dave's v2: Split from larger patch and add commit message Update kernel-doc (Reinette) Changes since v3: Swap parameter order (Reinette) Change summary prefix include fs/resctrl (Reinette) val -> @val Add Reinette's R-b Changes since v4: Set author to Dave as he wrote the patch --- arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 6 ++++++ include/linux/resctrl.h | 19 +++++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cp= u/resctrl/ctrlmondata.c index e74f1ed54b86..62044489b052 100644 --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c @@ -16,9 +16,15 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt =20 #include +#include =20 #include "internal.h" =20 +u32 resctrl_arch_preconvert_bw(const struct rdt_resource *r, u32 val) +{ + return roundup(val, (unsigned long)r->membw.bw_gran); +} + int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain= *d, u32 closid, enum resctrl_conf_type t, u32 cfg_val) { diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h index dd09c2ce9a0f..10dfdca7f4bf 100644 --- a/include/linux/resctrl.h +++ b/include/linux/resctrl.h @@ -505,6 +505,25 @@ bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_r= esource *r); */ int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable); =20 +/** + * resctrl_arch_preconvert_bw() - Prepare bandwidth control value for arch= use. + * @r: Resource whose schema was written. + * @val: Bandwidth control value written to the schemata file by userspace. + * + * Convert the user provided bandwidth control value to an appropriate for= m for + * consumption by the hardware driver for resource @r. Converted value is = stored + * in rdt_ctrl_domain::staged_config[] for later consumption by + * resctrl_arch_update_domains(). Is not called when MBA software controll= er is + * enabled. + * + * Architectures for which this pre-conversion hook is not useful should s= upply + * an implementation of this function that just returns @val unmodified. + * + * Return: + * The converted value. + */ +u32 resctrl_arch_preconvert_bw(const struct rdt_resource *r, u32 val); + /* * Update the ctrl_val and apply this config right now. * Must be called on one of the domain's CPUs. --=20 2.43.0 From nobody Fri Sep 25 13:55:23 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 297604A4828; Fri, 11 Sep 2026 16:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789144590; cv=none; b=BnZv7KiyEH1FeTHGehoS1r5wO2im+k4i4o5/PT+dFfJo+ZLvnd833/11oPX1B4jKyyy/mFSkbTWbbpggTAuUchHxehDW7R2LOUnqVRWvZCE91lTtDPNX1Md9p+wBauzI7kFl0PKH4otamkUflYTP4Hm2/z5BGl17dLJHSXi8Nvg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789144590; c=relaxed/simple; bh=ZgKXKOLm2sYRf235h4zu/DkzNsUkg7Z3/2TgHyl4z9c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t5/g7Z3dLfOyyG7ghMjBM9l6rzdLO4CC8CDT3SwBu5/gUb+asumtTgg7negDraX9UgCohEJpgAloVgnyie/BUjpCabKiuxr44NRFaEsTu28/m6TrmSdP9OlYr2Bx+nYSuNgmWOrAmhIBq9FRGexWj9bMkEZzrFgG9jF9DjRTkPM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=u2RygQWR; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="u2RygQWR" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DA0F52BC6; Fri, 11 Sep 2026 09:36:24 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C5F8A3F7B4; Fri, 11 Sep 2026 09:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1789144588; bh=ZgKXKOLm2sYRf235h4zu/DkzNsUkg7Z3/2TgHyl4z9c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=u2RygQWRT3uOLI+4If3Ryjn1uxH4/dkKQX9AekeN1gGRpLuuXdT3h9RuWpKuvDnYB d8ujEEnNiHxLD/A4NSMpYyQd0k/hQLUpuFa8MoQ08YFpOju6V4toDTRwpBeRmX6EF8 sg8ZGEMySu4emD0Yuh2QjWGvl0M6oMKGwtegndOw= From: Ben Horgan To: ben.horgan@arm.com Cc: james.morse@arm.com, reinette.chatre@intel.com, fenghuay@nvidia.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, corbet@lwn.net, x86@kernel.org, linux-doc@vger.kernel.org, dave.martin@arm.com Subject: [PATCH v6 2/3] arm_mpam: resctrl: Add pass-through resctrl_arch_preconvert_bw() Date: Fri, 11 Sep 2026 17:36:12 +0100 Message-ID: <20260911163613.1131447-3-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911163613.1131447-1-ben.horgan@arm.com> References: <20260911163613.1131447-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" resctrl rounds up the percentage value of the MBA based on the bw_gran. As MPAM uses a binary fixed point fraction format for MBA rather than a decimal percentage, this introduces rounding errors. Without this additional rounding, if the user reads the value in an MB schema and then writes it back to the schema, the value in hardware won't change. However, with this additional rounding, this guarantee is broken for systems with mbw_wd < 7. resctrl is introducing resctrl_arch_preconvert_bw() to allow the arch code to specify the conversion resctrl does to the user-provided bandwidth value. Add the MPAM version of resctrl_arch_preconvert_bw(). This does no conversion. Signed-off-by: Ben Horgan Reviewed-by: Reinette Chatre Reviewed-by: Gavin Shan --- Changes since v3: Parameter order switch (Reinette) Add Reinette's R-b Changes since v4: Add missing tearoff divider, --- --- drivers/resctrl/mpam_resctrl.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c index 9d223057953a..f2c651e9f6ea 100644 --- a/drivers/resctrl/mpam_resctrl.c +++ b/drivers/resctrl/mpam_resctrl.c @@ -148,6 +148,11 @@ bool resctrl_arch_get_cdp_enabled(enum resctrl_res_lev= el rid) return mpam_resctrl_controls[rid].cdp_enabled; } =20 +u32 resctrl_arch_preconvert_bw(const struct rdt_resource *r, u32 val) +{ + return val; +} + /** * resctrl_reset_task_closids() - Reset the PARTID/PMG values for all task= s. * --=20 2.43.0 From nobody Fri Sep 25 13:55:23 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5C50925771; Fri, 11 Sep 2026 16:36:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789144593; cv=none; b=nA1u03KG6gSPDTrHrDMdHHOhWFvfgQY2Lv7XAGXvuTVaN6X/WBmVTAK3AbVcyXk+KvsUVUak6/TLBMvv+ju8tlahrkqftroBshf9Vj201TBhsHe8AN7gA8l/XeOvC2EC34vl5/AAMZD5mlIIxfMSV/uhnt+iyVOlf7aOo6V43d8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789144593; c=relaxed/simple; bh=H44AQj3oR+IQy3azOI/ivx0DJ8iUEA1Ay8aEgAaMp74=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sNPbUHo4GseVxn3vHZp66wBZ8CML4QZtnFZ60VkGm4X8xsVvnDJh8D6spQaAOuvGQvNYE6XOiy4twoSZc7F883zN2xZXerDD3L5UxwvWIbgMB8HKFd0zcGGsstQ18tRkUL1R5AcuXL1/WqgGMEyl5MMXoFLcWMaWxnZNVUjewIQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=pfrvmLHi; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="pfrvmLHi" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 184702BCA; Fri, 11 Sep 2026 09:36:27 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id C94F83F7B4; Fri, 11 Sep 2026 09:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1789144590; bh=H44AQj3oR+IQy3azOI/ivx0DJ8iUEA1Ay8aEgAaMp74=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pfrvmLHiSYUABsaFb68pCpbuD023bLB6gCZD5YWYKCuD1M3jlOlxGyWLhbzR94u8e anRMEe7HXVJR66B+h1MQOuMDFkaNbC9HXaPVMPlJl9ohbaBgXg9dtX1BCiii3AUwa2 QDK0M8jSxKR3P0gkpfku2Y1tYYd84EXsX1pv9xWU= From: Ben Horgan To: ben.horgan@arm.com Cc: james.morse@arm.com, reinette.chatre@intel.com, fenghuay@nvidia.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, corbet@lwn.net, x86@kernel.org, linux-doc@vger.kernel.org, dave.martin@arm.com, Dave Martin , Ben Horgan Subject: [PATCH v6 3/3] fs/resctrl: Factor MBA parse-time conversion to be per-arch Date: Fri, 11 Sep 2026 17:36:13 +0100 Message-ID: <20260911163613.1131447-4-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260911163613.1131447-1-ben.horgan@arm.com> References: <20260911163613.1131447-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dave Martin The control value parser for the MB resource currently coerces the memory bandwidth percentage value from userspace to be an exact multiple of the rdt_resource::resctrl_membw::bw_gran parameter. On MPAM systems, this results in somewhat worse-than-worst-case rounding, s= ince the bandwidth granularity advertised to resctrl by the MPAM driver is in ge= neral only an approximation to the actual hardware granularity on these systems, = and the hardware bandwidth allocation control value is not natively a percentag= e -- necessitating a further conversion in the resctrl_arch_update_domains() pat= h, regardless of the conversion done at parse time. For MPAM and x86 use their custom pre-prepared parse-time conversion, resctrl_arch_preconvert_bw(). This will avoid accumulated error from roundi= ng the value twice on MPAM systems. For x86 systems there is no functional cha= nge. Clarify the documentation, but avoid overly exact promises. Clamping to bw_min and bw_max still feels generic: leave it in the core cod= e, for now. [ BH: Split out x86 specific changes ] Signed-off-by: Dave Martin Signed-off-by: Ben Horgan Reviewed-by: Ben Horgan Reviewed-by: Reinette Chatre Reviewed-by: Gavin Shan --- Changes since v3: Parameter order swap (Reinette) Reflow commit message to use 80 characters (Reinette) Adjust comment line length (Reinette) Add Reinette's R-b Changes since v4: Make Dave the author as he wrote the patch Changes since v5: Document that the rounding can be up or down --- Documentation/filesystems/resctrl.rst | 17 +++++++++-------- fs/resctrl/ctrlmondata.c | 6 +++--- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesyst= ems/resctrl.rst index e4b66af55ffb..dd4f80da419c 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -236,12 +236,11 @@ with respect to allocation: user can request. =20 "bandwidth_gran": - The granularity in which the memory bandwidth - percentage is allocated. The allocated - b/w percentage is rounded off to the next - control step available on the hardware. The - available bandwidth control steps are: - min_bandwidth + N * bandwidth_gran. + The approximate granularity in which the memory bandwidth + percentage is allocated. The allocated bandwidth percentage is + rounded up or down to the closest control step available on the + hardware. The available hardware steps are no larger than this + value. =20 "delay_linear": Indicates if the delay scale is linear or @@ -881,8 +880,10 @@ The minimum bandwidth percentage value for each cpu mo= del is predefined and can be looked up through "info/MB/min_bandwidth". The bandwidth granularity that is allocated is also dependent on the cpu model and can be looked up at "info/MB/bandwidth_gran". The available bandwidth -control steps are: min_bw + N * bw_gran. Intermediate values are rounded -to the next control step available on the hardware. +control steps are, approximately, min_bw + N * bw_gran. The steps may +appear irregular due to rounding to an exact percentage: bw_gran is the +maximum interval between the percentage values corresponding to any two +adjacent steps in the hardware. =20 The bandwidth throttling is a core specific mechanism on some of Intel SKUs. Using a high bandwidth and a low bandwidth setting on two threads diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c index 18ec9f564b5a..cafebdff70dc 100644 --- a/fs/resctrl/ctrlmondata.c +++ b/fs/resctrl/ctrlmondata.c @@ -37,8 +37,8 @@ typedef int (ctrlval_parser_t)(struct rdt_parse_data *dat= a, /* * Check whether MBA bandwidth percentage value is correct. The value is * checked against the minimum and max bandwidth values specified by the - * hardware. The allocated bandwidth percentage is rounded to the next - * control step available on the hardware. + * hardware. The allocated bandwidth percentage is converted as appropriate + * for consumption by the specific hardware driver. */ static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r) { @@ -71,7 +71,7 @@ static bool bw_validate(char *buf, u32 *data, struct rdt_= resource *r) return false; } =20 - *data =3D roundup(bw, (unsigned long)r->membw.bw_gran); + *data =3D resctrl_arch_preconvert_bw(r, bw); return true; } =20 --=20 2.43.0