From nobody Thu Apr 2 22:12:11 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ADAF43F2119 for ; Thu, 26 Mar 2026 17:26:06 +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=1774545968; cv=none; b=rWNvj6GgZbL41rJrogaFsC1x5phG0IE/7n6cT2mNkCBcaRCEOCKNzjkXgBh4TlC5xh/c6TmONSLYROEeRcXpfFbvoDB1TD6AAsk7PpsNLTpXjCI9iTW2CAlMZJGx8ynO4nQG9T6l2GdTxVkpqLP/vXO9y0xvCWrv1I4qgBnyvDI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545968; c=relaxed/simple; bh=9WRFiAuyxU+s3hWTEqddPln67W/ewp1pGFhWkyWHvnc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EH4z9TgM/NnnHbXH+EU8zslOdGadEWLSMowOL7UHQlLopSSWK9xs9B8Hv4f1ACHenxDajqE4JeNAXHXCmhI1PhAn0/4zad6xhDzsZrPo5ekj5ZCZqZpM3VQX+bOi/eb6RheyIScqSPHmgjpHBrqJp0LMYLy/4OQYxD0QNg2cQxo= 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=HxZfSzCo; 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="HxZfSzCo" 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 3BA982E9D; Thu, 26 Mar 2026 10:26:00 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5EC2A3F641; Thu, 26 Mar 2026 10:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545966; bh=9WRFiAuyxU+s3hWTEqddPln67W/ewp1pGFhWkyWHvnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HxZfSzCo31y9EYvpXmXsK/+6OLJiwfQXGNnVuB3O3FQ1c/XX1lr4FFHCRCKTsbak/ owYlgfFvTqPNWd1Mv8azwEZdu5ovTfd/mOHXTRknhp6r76HDBbEyLeIg2wCy1abwbn 88RcRdo3uFdyANes0ZkGgKYKPcmDqAcgOYad/rbU= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 3/7] fs/resctrl: Disallow the software controller when MBM counters are assignable Date: Thu, 26 Mar 2026 17:25:47 +0000 Message-ID: <20260326172551.1553871-4-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-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" The software controller requires that for each MBA control there is one MBM counter per monitor group that is assigned to the event backing the software controller, as per mba_MBps_event. When mbm_event mode is in use, it is not guaranteed that any particular event will have an assigned counter. Currently, only AMD systems support counter assignment, but the MBA delay is non-linear and so the software controller is never supported anyway. On MPAM systems, the MBA delay is linear and so the software controller could be supported. The MPAM driver, unless a need arises, will not support the 'default' mbm_assign_mode and will always use the 'mbm_event' mode for memory bandwidth monitoring. Rather than develop a way to guarantee the counter assignment requirements needed by the software controller, take the pragmatic approach. Don't allow the software controller to be used at the same time as 'mbm_event' mode. As MPAM is the only relevant architecture and it will use 'mbm_event' mode whenever there are assignable MBM counters, for simplicity's sake, don't allow the software controller when the MBM counters are assignable. Implement this by failing the mount if the user requests the software controller, the mba_MBps option, and the MBM counters are assignable. Signed-off-by: Ben Horgan --- fs/resctrl/rdtgroup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index fa5712db3778..7ef316b24a41 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -2528,7 +2528,8 @@ static bool supports_mba_mbps(void) =20 return (resctrl_is_mbm_enabled() && r->alloc_capable && is_mba_linear() && - r->ctrl_scope =3D=3D rmbm->mon_scope); + r->ctrl_scope =3D=3D rmbm->mon_scope && + !rmbm->mon.mbm_cntr_assignable); } =20 /* @@ -2943,7 +2944,7 @@ static int rdt_parse_param(struct fs_context *fc, str= uct fs_parameter *param) ctx->enable_cdpl2 =3D true; return 0; case Opt_mba_mbps: - msg =3D "mba_MBps requires MBM and linear scale MBA at L3 scope"; + msg =3D "mba_MBps requires dedicated MBM counters and linear scale MBA a= t L3 scope"; if (!supports_mba_mbps()) return invalfc(fc, msg); ctx->enable_mba_mbps =3D true; --=20 2.43.0