From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4E00A396565 for ; Fri, 27 Mar 2026 17:24:22 +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=1774632264; cv=none; b=rcx/b5hf7/06/pU+nFC6z+ohKb7PmNmPphKWwN2BrWRcLH20VvoV4b3veNVi4O8qra6g8bwWlEuwESqU9OAV3F+rs5AE/8RWs0Z9m1SU57VzTRrDODQxpIKmP5ajrNoENW5w+lDOQU4mwD6RI9LefpPQOnMi0JO47vdsbvto4eE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774632264; c=relaxed/simple; bh=FcG9x97FGtynjb60mpyXMkomBTutrTdbthvn5zy1SO8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NUimpAyMvW2lpEm297pP79dzlhKJ6S6gkP/5KBKlvSB2kr5Io/D6ttu6zbViGXeel2QhN8VROVtfi6PlW/gXsRpaHyVlFYeq7SQZY4qszRXiRDFxc7PVihtxndSOg0dvvfTB5GFzGIwyocCF5dA2ralxiquGXo5RwVffd7WK1Hg= 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=aST0nLsw; 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="aST0nLsw" 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 A97D635AA; Fri, 27 Mar 2026 10:24:15 -0700 (PDT) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EC8CC3F99C; Fri, 27 Mar 2026 10:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774632261; bh=FcG9x97FGtynjb60mpyXMkomBTutrTdbthvn5zy1SO8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=aST0nLswREAD+qEtm7N8VtlLBrqEpO/tnFb2XUt8l575VfSkPXUJR6uR5szXu1jG4 fBPaOZD4U3vQZTSc0+qXKPNd7uKNR1+KplsSFnbJfuUNImKULbEReu2h6ktdF7e/i5 Ds1SJSjC6bTZk7MSash69Bj5wks7KZtWJyzIGUmk= Message-ID: Date: Fri, 27 Mar 2026 17:24:18 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [PATCH v4 3/7] fs/resctrl: Disallow the software controller when MBM counters are assignable To: Reinette Chatre , linux-kernel@vger.kernel.org Cc: tony.luck@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, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com References: <20260326172551.1553871-1-ben.horgan@arm.com> <20260326172551.1553871-4-ben.horgan@arm.com> Content-Language: en-US From: Ben Horgan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 3/27/26 16:14, Reinette Chatre wrote: > Hi Ben, > > On 3/26/26 10:25 AM, Ben Horgan wrote: >> The software controller requires that for each MBA control there is one MBM > > Could you please elaborate the "for each MBA control" distinction here? I was referring to the per-control per-domain configurable bandwidth but perhaps it's clearer to just drop "for each MBA control" from the sentence. > >> 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) >> >> return (resctrl_is_mbm_enabled() && >> r->alloc_capable && is_mba_linear() && >> - r->ctrl_scope == rmbm->mon_scope); >> + r->ctrl_scope == rmbm->mon_scope && >> + !rmbm->mon.mbm_cntr_assignable); >> } >> >> /* >> @@ -2943,7 +2944,7 @@ static int rdt_parse_param(struct fs_context *fc, struct fs_parameter *param) >> ctx->enable_cdpl2 = true; >> return 0; >> case Opt_mba_mbps: >> - msg = "mba_MBps requires MBM and linear scale MBA at L3 scope"; >> + msg = "mba_MBps requires dedicated MBM counters and linear scale MBA at L3 scope"; > > This looks like the original. I was expecting: > https://lore.kernel.org/lkml/cac437e2-8139-4833-9cbd-55d626062730@arm.com/ ? Ah, sorry! Updated locally now. Thanks, Ben > >> if (!supports_mba_mbps()) >> return invalfc(fc, msg); >> ctx->enable_mba_mbps = true; > > Reinette