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 1B2C1337105 for ; Tue, 5 May 2026 10:20:49 +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=1777976451; cv=none; b=oGhGES5Y6EMLLLy/ZkJ2e/2QnGUkzBqql48PgUPPsLxcXfItBxtoyt4Ei/CanfANkQwf4PPVR6A8OH5UP3UpYrlnHGpKMICLQtyEgH9Db/XBhYTGMdQnK3MnSwT6IKtweH+GPMSWXDs0FfK4UG7/LjKylaeTWoZnFBG75fqZrHo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777976451; c=relaxed/simple; bh=l2KMbc/EwLHgNkK5v7/kFlmj/fulczwxBlW53qBLlSE=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=IqMCjw0xZkrFYErvYd/zceIqj6vEiUKAJaPktC4bZnrEMaHKDKj181OZqvfmk713h/4XyeU/ZYZ9rheB+0+CoISJpG47bYKvqHNf0ljPAuTx5cjVUM6bpeyRV/SmIL0fahpTzB88IruaFJiXt7UxXjwACFGrqz5OKQaP5jXCgvQ= 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=POnz0lRC; 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="POnz0lRC" 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 D95042936; Tue, 5 May 2026 03:20:43 -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 53BF13F763; Tue, 5 May 2026 03:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1777976449; bh=l2KMbc/EwLHgNkK5v7/kFlmj/fulczwxBlW53qBLlSE=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=POnz0lRCmcOHc2jGbnNFb6mE/JVXB8XVED9NF7RK1BPjUj4kOJktfGcBh/pYN6el/ anga/4556ZL56Hl6GivptklTqDYLnd3DBqvBZedjIZwi+EgWMvRIUHTaoDmv+A95AQ UTJH0YJnZ6KX1Mhty1naycq9VAYTzvIZBLXNiKow= Message-ID: <50f80205-09a4-4883-aa44-35d41aa780fc@arm.com> Date: Tue, 5 May 2026 11:20:45 +0100 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 v5 3/7] fs/resctrl: Disallow the software controller when MBM counters are assignable From: Ben Horgan 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: <20260428130422.2287302-1-ben.horgan@arm.com> <20260428130422.2287302-4-ben.horgan@arm.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/5/26 10:34, Ben Horgan wrote: > Hi Reinette, > > On 5/4/26 17:01, Reinette Chatre wrote: >> Hi Ben, >> >> On 4/28/26 6:04 AM, Ben Horgan wrote: >> >>> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c >>> index b382a348dd79..be84bb210e3a 100644 >>> --- a/fs/resctrl/rdtgroup.c >>> +++ b/fs/resctrl/rdtgroup.c >>> @@ -2530,7 +2530,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); >>> } >> >> For better or worse supports_mba_mbps() has a function description that documents >> the above tests. Updating the tests but not the accompanying description creates >> an inconsistency. How about something like below? >> >> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c >> index 36d21652616e..b456a67b2c24 100644 >> --- a/fs/resctrl/rdtgroup.c >> +++ b/fs/resctrl/rdtgroup.c >> @@ -2536,10 +2536,12 @@ static void mba_sc_domain_destroy(struct rdt_resource *r, >> } >> >> /* >> - * MBA software controller is supported only if >> - * MBM is supported and MBA is in linear scale, >> - * and the MBM monitor scope is the same as MBA >> - * control scope. >> + * MBA software controller is supported only if MBM is supported and MBA is in >> + * linear scale, and the MBM monitor scope is the same as MBA control scope. >> + * >> + * Software controller cannot be supported when the MBM counters are assignable. >> + * There is no guarantee that MBM counters are assigned to the event backing >> + * the software controller in all monitoring domains of all monitoring groups. > > Yes, that makes sense to me. I'll use that. I've add 'The' to the start of the first two sentences as that makes it read a bit better to me. That ends up as: /* * The MBA software controller is supported only if MBM is supported and MBA is * in linear scale, and the MBM monitor scope is the same as MBA control scope. * * The software controller cannot be supported when the MBM counters are * assignable. There is no guarantee that MBM counters are assigned to the * event backing the software controller in all monitoring domains of all * monitoring groups. */ Thanks, Ben > > Thanks, > > Ben > >> */ >> static bool supports_mba_mbps(void) >> { >> >>> >>> /* >>> @@ -2945,7 +2946,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 MBM (mbm_event mode not supported) and linear scale MBA at L3 scope"; >>> if (!supports_mba_mbps()) >>> return invalfc(fc, msg); >>> ctx->enable_mba_mbps = true; >> >> Reinette >