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 7391336BCEB for ; Tue, 3 Mar 2026 14:00:40 +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=1772546442; cv=none; b=S5HWLLyUZRzdhCajwivRdvDt5ccDYgDfF5YujffZAkc5K+xXcTJUEn/BFafMpGnVjUfjSrb+skpyzcbNfcQP9AU549xdtU/pZbznOFaJlI4xEh2lnJh/s03VXGxSd2hNld+d+3oIu4aTUDRufnxu9/AJ3gOWarOkgmf3xtMp9Lc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772546442; c=relaxed/simple; bh=NQ9gniT/25YVNKjlONXuDrdSC3LF7r69guSQPLjFyng=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nU2t4yvdFdFB5RsUV+c68PwhSLfV2j8XhM4rQ1rFrmHpprZGMMlmVuv/SB1mc/pIiVMtVpd1AKvHO6g42T0FBCnPIdCXKjRloODi8RgO/ckkc8yZkZeW1+lSHX6P6Ur89lLVvBCbXhOzNRuuy6C+a66UCbY3CzZi8y1d5Q4MCtY= 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 2F659497; Tue, 3 Mar 2026 06:00:33 -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 77F993F73B; Tue, 3 Mar 2026 06:00:37 -0800 (PST) Date: Tue, 3 Mar 2026 14:00:35 +0000 From: Ben Horgan To: Reinette Chatre Cc: linux-kernel@vger.kernel.org, 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 Subject: Re: [PATCH v1 2/4] fs/resctrl: Only show 'event_filter' files if events are configurable Message-ID: References: <20260225201905.3568624-1-ben.horgan@arm.com> <20260225201905.3568624-3-ben.horgan@arm.com> <7c043aae-7495-4fa9-a630-ec9e1606cee5@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: <7c043aae-7495-4fa9-a630-ec9e1606cee5@intel.com> Hi Reinette, On Mon, Mar 02, 2026 at 03:12:52PM -0800, Reinette Chatre wrote: > Hi Ben, > > On 2/25/26 12:19 PM, Ben Horgan wrote: > > When the counter assignment mode is mbm_event resctrl assumes the mbm > > events are configurable and exposes the 'event_filter' files. These files > > live at info/L3_MON/event_configs//event_filter and are used to > > display and set the event configuration. > > > > ABMC always supports event configuration but for MPAM they are > > independent. Decouple event configuration from counter assignment by only > > Could you please elaborate what you mean with "independent" here? If event > configuration is still supported when assignable counter mode is enabled, why > can event configuration interface not just remain as-is? Could resctrl not The two features of ABMC that I'm claiming are independent are: firstly, requiring assignment of a hardware counter to to CTRL_MON/MON group in order to allow using bandwidth monitoring when there are fewer hardware counters than possible CTRL_MON/MON groups (num_rmid) and secondly bandwidth type configuration for the counters. The first is concerned with which, if any, hardware counter is used per group and the second with what the counters are counting. To me these as appear as two things that should be considered separatedly. Is this clearer? I'm first trying to address the case where event configuration isn't supported as we haven't currently got support for that in the MPAM driver and supporting systems with fewer hardware counters than (PARTID, PMG) without unnecessary limiting the exposed PARTID/PMG. Some MPAM hardware systems only have a single bandwidth counter. > display the existing event configuration and if user cannot modify it return > a failure when user attempts to do so? I guess it could. Currently in MPAM we just support mbm_total_bytes and so it would always be 0x1F. Would we want some other way to indicate that it is fixed rather than trying to change it? However, if we just remove the configuration files then it seems natural for mbm_total_bytes to just have the same meaning as it has when BMEC and ABMC are not enabled. > > Reinette > Thanks, Ben