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 8030C37DEAA for ; Tue, 3 Mar 2026 14:24:38 +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=1772547879; cv=none; b=Oqd9vvy1GBYJ/iL7IVea/7hvQfINAp+kxG1r/UG1X9DHWLYZt2WhmXylMSNK2Szj9m9LWB62r43PVOIPHlPr2kNqyrQCk4MapfaZCvPe/ltFTnCYfjH/luz/BESAbZL8bszsIhS4TJQ3KnGj3jMCQpc10oeynL7YfOEa8UhSjkI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772547879; c=relaxed/simple; bh=HFXrdaaqD5hGr1YcylEruVHQdGlk09Z3g/vyZPpGH30=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ub2yqZ7EGjYi0aFBrfPCbC4XQwjcnGA4DYKC/+TTWZxhBGdFkIqpDDdhsejnpgYcNnqeAypttW+sCiYQmrpsFHoFRpIdLsj3t+JFQMI/Ik1lQLwqxTEGPH2QP7PT/0mV1yysy+rMNgz1DDKPWSfw6kBRrpNl6253YU6FfkUvCM8= 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; 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 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 A3AE2497; Tue, 3 Mar 2026 06:24:31 -0800 (PST) Received: from e134344.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CF2E93F694; Tue, 3 Mar 2026 06:24:36 -0800 (PST) Date: Tue, 3 Mar 2026 14:24:28 +0000 From: Ben Horgan To: Reinette Chatre Cc: Borislav Petkov , linux-kernel@vger.kernel.org, tony.luck@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com Subject: Re: [PATCH v4] fs/resctrl: Add CONFIG_RESCTRL_ASSIGN_FIXED Kconfig entry Message-ID: References: <20260204161952.685921-1-ben.horgan@arm.com> <20260301104918.GCaaQZrlomC0Bw-wM3@fat_crate.local> <9b2c1318-3f59-4d21-8b15-922bdac8114c@arm.com> <486d59a6-4c8b-49e3-a1d1-673c9224bce2@intel.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: <486d59a6-4c8b-49e3-a1d1-673c9224bce2@intel.com> Hi Reinette, On Mon, Mar 02, 2026 at 03:32:39PM -0800, Reinette Chatre wrote: > Hi Ben, > > On 3/2/26 2:02 AM, Ben Horgan wrote: > > Hi Boris, > > > > On 3/1/26 10:49, Borislav Petkov wrote: > >> On Wed, Feb 04, 2026 at 04:19:52PM +0000, Ben Horgan wrote: > >>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c > >>> index 572a9925bd6c..4e9f55ee3267 100644 > >>> --- a/fs/resctrl/monitor.c > >>> +++ b/fs/resctrl/monitor.c > >>> @@ -1451,6 +1451,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_open_file *of, char *buf, > >>> } > >>> > >>> if (enable != resctrl_arch_mbm_cntr_assign_enabled(r)) { > >>> + if (IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) { > >> > >> Does it need to be a Kconfig entry or you can figure out programatically from > >> the architecture that that is the case and avoid yet another CONFIG_ knob? > >> > >> From reading this, I'm thinking > >> > >> if (IS ARM64) { > >> > >> should do or...? > > > > Yes, we don't necessarily need the Kconfig and we don't necessarily need this condition at all in > > resctrl_mbm_assign_mode_write(), we do need the existing one in resctrl_mbm_assign_mode_show() though. > > It is not obvious to me why the one in resctrl_mbm_assign_mode_show() is required if > a new arch helper could suffice in other parts I think a new arch helper could cover both. > > > > > The Kconfig was effectively added in: > > > > commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring modes") > > > > and I was just filling in the missing piece. Most arch specific things in resctrl seem > > to be dealt with using resctrl_arch_* hooks. Would it be preferable to create a new one of these? > > It looks to me as though this patch fits in with the other series you posted at > https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/ > > When looking at this patch together with the other series there may indeed be an arch > helper that can replace CONFIG_RESCTRL_ASSIGN_FIXED but as I mentioned in that series > the MPAM capabilities and strategies for resctrl to support them are not clear to me > at this time. If you like, I can drop this patch and tag a resctrl_arch_ hook based hook version on to that series when I respin. Do you prefer a new hook, resctrl_arch_mbm_cntr_assign_fixed(), or using/abusing the error return of resctrl_arch_mbm_assign_set()? > > > > It could be resctrl_arch_mbm_cntr_assign_fixed() although we seem to be getting too many > > of these too. Perhaps we could extend the meaning of another hook, resctrl_arch_mbm_assign_set() could > > Could you please elaborate which category of helper is getting to be too many? We can surely > explore improvements. Nothing major or anything that necessarily needs to change. Just that for each new feature we get a few new resctrl_arch_* and they all need to be updated in the MPAM driver even if the feature isn't used. > > > return -EOPNOTSUPP to indicate to resctrl that the counter assignment mode is not configurable. > > > > Reinette > Thanks, Ben