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 5A4E03CCA08 for ; Wed, 4 Mar 2026 17:53:07 +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=1772646789; cv=none; b=eaYmtkXiWhArd4oaCgFsW/RAJIi+xKHrMh8+/2PBseAhskHC1RneNRTiRgv942FI100W9mhrnIPhE3bBlaJy/DBMxddL87okMvllJQhw+LG4wO0F2bLCyZRZ3GSyaBTaE+cHzgHeJWIKqmlSLr/QiS7KgNrsA2nXk8GP1GCRVes= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772646789; c=relaxed/simple; bh=+36KP5rPPrc1aSqOIgNHovxnr1BZaYdICmj9TbO3GFo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CWHWLpjm259UwPAin8oi70aNJre+LCc6d06rCPCOYq/LfocmlvgxeklFn13GNxNdHT6BLJVsGm6rrQbNAFngEgDbZY8w3qCf0NqQvQcyd+OW/jT/gfXOdJakhO/3Nbo9La1J4z+A5Vjgl/7T85vNB+8goeHPZ74/lqFNuVnnnJE= 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 3B9C0339; Wed, 4 Mar 2026 09:53:00 -0800 (PST) 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 9AD913F73B; Wed, 4 Mar 2026 09:53:04 -0800 (PST) Message-ID: <5e32a208-3f1f-444f-b821-b9b53e6b5799@arm.com> Date: Wed, 4 Mar 2026 17:53:03 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/4] fs/resctrl: Only show 'event_filter' files if events are configurable 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 References: <20260225201905.3568624-1-ben.horgan@arm.com> <20260225201905.3568624-3-ben.horgan@arm.com> <7c043aae-7495-4fa9-a630-ec9e1606cee5@intel.com> <806ef407-c2ee-438c-ab93-30cbceb1193c@intel.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <806ef407-c2ee-438c-ab93-30cbceb1193c@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 3/4/26 17:03, Reinette Chatre wrote: > Hi Ben, > > On 3/4/26 3:31 AM, Ben Horgan wrote: >> Hi Reinette, >> >> On 3/3/26 18:14, Reinette Chatre wrote: >>> Hi Ben, >>> >>> On 3/3/26 6:00 AM, Ben Horgan wrote: >>>> 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. >>> >>> These are implemented separately in resctrl fs. >>> >>> >>>> 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? >>> >>> They can, and indeed resctrl manages these two parts of assignable counters with >>> two separate interfaces. >>> >>>> >>>> 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. >>> >>> ok, but if assignment is supported first then that assignment needs to have some >>> configuration associated with it as to which memory transactions are counted, no? >>> >>> If I understand correctly MPAM would have hardcoded events (hardcoded which >>> transactions are counted by current default mbm_total_bytes and/or mbm_local_bytes). >>> The memory transactions that the event counts can be exposed in the >>> associated event_filter file. User space can use the per-resource group >>> mbm_L3_assignments file to assign the event to the resource group that will >>> result in counter allocated and programmed to count those transactions for >>> that resource group. >> >> That's right. >> >> Just wondering, why aren't there _L3_assignments files to >> allow keeping all CTRL_MON/MON groups when there are, as pointed out in >> the Documentation/filesystems/resctrl.rst, platforms with limited >> telemetry counters? > > Apologies but I do not understand this question. Are you referring to the new > telemetry monitoring feature? Yes, it's not important, but I was just wondering if the telemetry monitoring feature had the same counter scarcity problem that the counter assignment feature addresses and if it was solved in the same way. Although, I realise it may just be to do with the number of rmid supported for telemetry. > >>> With only one bandwidth counter it will only be possible to assign one event to >>> one resource group at a time. >> >> yes >> >>> >>>> >>>>> 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 >>> >>> event_filter could also be made readable only. This sounds temporary though and at >>> some point the MPAM driver will support event configuration. I thus do not think >>> resctrl fs should make big interface changes to accommodate this. >> >> For MPAM, some of the bits will always be unchangeable as they depend on >> which hardware counter rather than the configuration of that hardware >> counter. Also, not all MPAM hardware supports the read/write configuration. > > This seems to tie in with discussion in other thread on how values for > mbm_total_bytes and mbm_local_bytes are computed. It almost sounds as though there > is just one bandwidth measurement returned from the various counters on the system > and that MPAM driver uses system knowledge to accumulated needed values and display > them to user space as these separate events. Let's concentrate on the other thread, but no. The MSC.RIS count single source and the driver only ever sums equivalent parts within a component. (I guess the hardware counters could be implemented using accumulation but, that's not our concern.) > >>>> 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. >>> >>> I do not see a reason to remove the configuration file. If MPAM just supports >>> mbm_total_bytes then user space can still look at its event_filter to see which >>> transactions are counted by it. I am not sure about the 0x1F you mention (was >>> expecting 0x7F), but below is how it would appear: >> >> 0x1F was a mistake, it is indeed 0x7F. >> >>> >>> # cat /sys/fs/resctrl/info/L3_MON/event_configs/mbm_total_bytes/event_filter >>> local_reads,remote_reads,local_non_temporal_writes,remote_non_temporal_writes, >>> local_reads_slow_memory >> >> Ok, it's not a natural description for MPAM bandwidth counters but I >> think we can live with that. > > What are the MPAM descriptions? We mainly talk about the placement of the MSC rather than bandwidth types. For mbm_total_bytes I'm just viewing that as all reads/writes leaving the L3. Bringing in the extra info temporal/slow_memory is just extra. Still, should be ok. > > Reinette > -- Thanks, Ben