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 88E6A8F49 for ; Thu, 5 Mar 2026 17:34:25 +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=1772732067; cv=none; b=GN0LqRGWt12aUitGrn/yN3PTx7RpSJ0LB8iMePOw7M+Y2r/0H3qPnuK+/5NnygCXM17c3e+3OYRwRuqNxPf54mBMqzmIoZEPH/JTvaPgL80n+Tt3shuh/DnfMlpcCUSpxwGuRlkq6+0g9DOpWgvpG2M01o9+GWKuu2D0ebcVPl8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772732067; c=relaxed/simple; bh=XOuRZz/n49IqDZycQmoNvAKKt+VlNRKvbKoWi0ceY2E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=A5uONCjRTVFyVuAk2xuP6lneOCYYgLTjzKTsr3XZ0bFvHzzj5QAvfLOkzvTcJ+pDubu1Z5gNL2eC6v10mYxuaXvR3j0lSDS2s1C6xEPwWZJY0fqZq2FnU3FZ0sucqnca2O6IIDs2MEGXcwq0n0zGWmxw9vVFntjHuyMoO/CIg3E= 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 5C8FC339; Thu, 5 Mar 2026 09:34:18 -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 B314A3F694; Thu, 5 Mar 2026 09:34:22 -0800 (PST) Message-ID: <62d38819-e43c-47c0-af4c-033bfe448912@arm.com> Date: Thu, 5 Mar 2026 17:34:21 +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 1/4] x86,fs/resctrl: Make resctrl_arch_is_evt_configurable() aware of mbm_assign_mode 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-2-ben.horgan@arm.com> <5645ee7f-a5d6-4b5e-ad54-d24a11268e35@arm.com> <94fca0a8-9b60-4e00-ac69-a4e43c5fcbc9@intel.com> <7c6a1986-b23e-48b7-acad-af67bbece2c4@arm.com> <9d980366-95b1-4c9c-b2d5-76314c72bbe7@intel.com> <7e5aede6-a1a5-483d-93e2-0c8b910bc3f6@arm.com> <39b9c59f-e001-4733-9afb-c9a0c7f279a4@intel.com> <940210db-1447-4a0e-8605-a3e83989afb2@intel.com> From: Ben Horgan Content-Language: en-US In-Reply-To: <940210db-1447-4a0e-8605-a3e83989afb2@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 3/5/26 17:22, Reinette Chatre wrote: > Hi Ben, > > On 3/5/26 2:01 AM, Ben Horgan wrote: >> On 3/4/26 22:50, Reinette Chatre wrote: >>> On 3/4/26 1:01 PM, Ben Horgan wrote: > >>>> So, to try and bring this back to what we can be done now for MPAM to >>>> fit into the counter mode assignment interface. Just support >>>> mbm_total_bytes and then num_mbm_cntrs is correct (nothing to do). Make >>>> the event_filter file always display all the bandwidth types and make >>>> that the only value that be the only value it accepts (instead of hiding >>>> the event_filter file). If you agree I'll respin with that. >>> >>> From resctrl side this sounds fine. I don't have any insight into what, if any, >>> kind of gymnastics the MPAM driver needs to do to make the discovered MSCs with >>> their varying scope and internal vs external counts fit into this. If initial >>> implementation indeed forces some components into categories that are not a good >>> match then when resctrl later does get support for diverse components there may >>> be surprises to user space along the way. For example, user space may not see the >>> same memory bandwidth numbers reported by the same events on the same system as >>> the interface evolves. >> >> Indeed, we have already weeded a few things out of the MPAM driver for >> similar reasons. If we start with mpam only supporting a >> non-configurable mbm_total_bytes with ABMC I think we're ok. I'll drop >> the non-ABMC bandwidth counter support from the MPAM driver as even if >> we've got enough counters, one per (CTRL_MON/MON, evt), we can use ABMC. > > It sounds like the expectation is that when there are enough counters the user > will then run with "mbm_assign_on_mkdir" set so that counters are always dynamically > assigned and thus essentially be "non-ABMC bandwidth counter support"? Yes, that's the intent. > Since "mbm_assign_on_mkdir" is set by default then user space should get sane > behavior by default. > > Alternatively, a user space would just always run with "mbm_assign_on_mkdir" > off and have full control over monitor assignment even when it is not necessary. > > Sounds good to me. > >> Also, when event configuration (read/write filtering) using user defined >> (or new) events is added this will mean that enough counters becomes a >> higher limit. That will mean that the software controller is not usable >> but for now I think we can just fail when that mount option, mba_MBps, >> is used. Later we can consider using non-ABMC bandwidth counters when >> the software controller is requested. > > ok. Since info/last_cmd_status is not available to to user when mount fail, > please do add a message to kernel log to help diagnose resctrl mount failure. > Yep, patch 3 does this. > >> >>> >>> "make that the only value that be the only value it accepts" - are you saying that >>> whatever is displayed when user views the "event_filter" file is what the >>> user can write to the "event_filter" file? I find this a challenging interface >>> for user space to use. The expectation is that the user can write any supported >>> memory transaction to that file and when writing fails it can only be because >>> of an invalid memory transaction. How can user space know that events are not >>> configurable at all? It sounds as though user space is expected to try configuring >>> the event with a memory transaction and then, presumably, check last_cmd_status? >>> >>> Could this not be simplified by making the "event_filter" file read-only on >>> MPAM systems? >> >> Yes, we'll need some finer grained control for which sets of bandwidth >> types can be configured further down the line but going with read-only >> for when there is only one fixed set seems good to me. > > Thank you very much. > > Reinette > Sounds like we've got a plan :) Thanks! Ben