mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
	corbet@lwn.net, tony.luck@intel.com, Dave.Martin@arm.com,
	james.morse@arm.com, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com
Cc: x86@kernel.org, hpa@zytor.com, akpm@linux-foundation.org,
	rostedt@goodmis.org, paulmck@kernel.org, thuth@redhat.com,
	ardb@kernel.org, gregkh@linuxfoundation.org, seanjc@google.com,
	thomas.lendacky@amd.com, pawan.kumar.gupta@linux.intel.com,
	manali.shukla@amd.com, perry.yuan@amd.com, kai.huang@intel.com,
	peterz@infradead.org, xiaoyao.li@intel.com,
	kan.liang@linux.intel.com, mario.limonciello@amd.com,
	xin3.li@intel.com, gautham.shenoy@amd.com, xin@zytor.com,
	chang.seok.bae@intel.com, fenghuay@nvidia.com,
	peternewman@google.com, maciej.wieczor-retman@intel.com,
	eranian@google.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v14 18/32] fs/resctrl: Add the functionality to assign MBM events
Date: Thu, 26 Jun 2025 14:31:50 -0500	[thread overview]
Message-ID: <95e675a6-5cec-4f14-bb57-eebffb6024a5@amd.com> (raw)
In-Reply-To: <77ce3646-2213-4987-a438-a69f6d7c6cfd@intel.com>



On 6/24/25 22:32, Reinette Chatre wrote:
> Hi Babu,
> 
> On 6/13/25 2:05 PM, Babu Moger wrote:
>> When supported "mbm_event" mode offers "num_mbm_cntrs" number of counters
> 
> "When supported, "mbm_event" counter assignment mode offers ..."?

Sure.

> 
>> that can be assigned to RMID, event pairs and monitor bandwidth usage as
>> long as it is assigned.
>>
>> Add the functionality to allocate and assign a counter ID to an RMID, event
>> pair in the domain.
>>
>> If all the counters are in use, kernel will log the error message "Unable
>> to allocate counter in domain" in /sys/fs/resctrl/info/last_cmd_status
>> when a new assignment is requested. Exit on the first failure when
>> assigning counters across all the domains.
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
> 
> ...
> 
>> ---
>>  fs/resctrl/internal.h |   3 +
>>  fs/resctrl/monitor.c  | 134 ++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 137 insertions(+)
>>
>> diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
>> index 71059c2cda16..0767a1c46f26 100644
>> --- a/fs/resctrl/internal.h
>> +++ b/fs/resctrl/internal.h
>> @@ -386,6 +386,9 @@ bool closid_allocated(unsigned int closid);
>>  
>>  int resctrl_find_cleanest_closid(void);
>>  
>> +int resctrl_assign_cntr_event(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +			      struct rdtgroup *rdtgrp, struct mon_evt *mevt);
>> +
>>  #ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
>>  int rdtgroup_locksetup_enter(struct rdtgroup *rdtgrp);
>>  
>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
>> index 3e1a8239b0d3..38800fe45931 100644
>> --- a/fs/resctrl/monitor.c
>> +++ b/fs/resctrl/monitor.c
>> @@ -950,3 +950,137 @@ void resctrl_mon_resource_exit(void)
>>  
>>  	dom_data_exit(r);
>>  }
>> +
>> +/**
>> + * resctrl_config_cntr() - Configure the counter ID for the event, RMID pair in
>> + * the domain.
>> + *
>> + * Assign the counter if @assign is true else unassign the counter. Reset the
>> + * associated non-architectural state.
> 
> A few reports came through about the kernel-doc issues but I did not see a
> discussion finalize on how to resolve them. I do not think it is required for these
> static functions to have full kernel-doc. Just having useful comments without
> kernel-doc style is valuable. Some kernel-doc syntax can still be useful though, like
> above when referring to the parameters. It is ok to keep doing so even if section
> does not start with /**. 

Sure. Thanks

> 
> Where I think kernel-doc is important is include/linux/resctrl.h.

Sure.

> 
>> + */
>> +static void resctrl_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +				enum resctrl_event_id evtid, u32 rmid, u32 closid,
>> +				u32 cntr_id, bool assign)
> 
> If resctrl_arch_config_cntr() does not need a struct resource then resctrl_config_cntr()
> may not either?
> 
>> +{
>> +	struct mbm_state *m;
>> +
>> +	resctrl_arch_config_cntr(r, d, evtid, rmid, closid, cntr_id, assign);
>> +
>> +	m = get_mbm_state(d, closid, rmid, evtid);
>> +	if (m)
>> +		memset(m, 0, sizeof(struct mbm_state));
> 
> sizeof(*m).

Sure.

> 
>> +}
>> +
>> +/**
>> + * mbm_cntr_get() - Return the counter ID for the matching @evtid and @rdtgrp.
>> + *
>> + * Return:
>> + * Valid counter ID on success, or -ENOENT on failure.
>> + */
>> +static int mbm_cntr_get(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +			struct rdtgroup *rdtgrp, enum resctrl_event_id evtid)
>> +{
>> +	int cntr_id;
>> +
> 
> Since mbm_cntr_get() is called in regular flows, could you please also
> add an explicit check to return -ENOENT if !r->mon.mbm_cntr_assignable?
> Otherwise this is quite subtle with the assumption that
> r->mon.num_mbm_cntrs is zero in this case.

Sure. Added the check.

if (!r->mon.mbm_cntr_assignable)
                return -ENOENT;


> 
>> +	if (!resctrl_is_mbm_event(evtid))
>> +		return -ENOENT;
>> +
>> +	for (cntr_id = 0; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) {
>> +		if (d->cntr_cfg[cntr_id].rdtgrp == rdtgrp &&
>> +		    d->cntr_cfg[cntr_id].evtid == evtid)
>> +			return cntr_id;
>> +	}
>> +
>> +	return -ENOENT;
>> +}
>> +
>> +/**
>> + * mbm_cntr_alloc() - Initilialize and return a new counter ID in the domain @d.
> 
> "Initilialize" -> "Initialize"

Sure.

> 
>> + *
> 
> mbm_cntr_alloc() will allocate a counter to a RMID/event pair even
> if that pair already has a counter assigned. The doc should note that caveat
> here with documentation that the caller is responsible for checking that
> a counter is not already assigned.
Added the text.

Caller must ensure that the specified event is not assigned already.

> 
>> + * Return:
>> + * Valid counter ID on success, or -ENOSPC on failure.
>> + */
>> +static int mbm_cntr_alloc(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +			  struct rdtgroup *rdtgrp, enum resctrl_event_id evtid)
>> +{
>> +	int cntr_id;
>> +
>> +	for (cntr_id = 0; cntr_id < r->mon.num_mbm_cntrs; cntr_id++) {
>> +		if (!d->cntr_cfg[cntr_id].rdtgrp) {
>> +			d->cntr_cfg[cntr_id].rdtgrp = rdtgrp;
>> +			d->cntr_cfg[cntr_id].evtid = evtid;
>> +			return cntr_id;
>> +		}
>> +	}
>> +
>> +	return -ENOSPC;
>> +}
>> +
>> +/**
>> + * resctrl_alloc_config_cntr() - Allocate a counter ID and configure it for the
>> + * event pointed to by @mevt and the resctrl group @rdtgrp within the domain @d.
>> + *
>> + * Return:
>> + * 0 on success, or a non-zero value on failure.
> 
> "or a non-zero value on failure." -> "<0 on failure"

Sure.

> 
>> + */
>> +static int resctrl_alloc_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +				     struct rdtgroup *rdtgrp, struct mon_evt *mevt)
>> +{
>> +	int cntr_id;
>> +
>> +	/* No need to allocate a new counter if it is already assigned */
>> +	cntr_id = mbm_cntr_get(r, d, rdtgrp, mevt->evtid);
>> +	if (cntr_id >= 0)
>> +		goto cntr_configure;
>> +
>> +	cntr_id = mbm_cntr_alloc(r, d, rdtgrp, mevt->evtid);
>> +	if (cntr_id <  0) {
>> +		rdt_last_cmd_printf("Unable to allocate counter in domain %d\n",
>> +				    d->hdr.id);
>> +		return cntr_id;
>> +	}
>> +
>> +cntr_configure:
>> +	/*
>> +	 * Skip reconfiguration if the event setup is current; otherwise,
>> +	 * update and apply the new configuration to the domain.
> 
> When could "event setup" *not* be current? As mentioned in earlier patch
> I do not see why mon_evt::evt_cfg as well as mbm_cntr_cfg::evt_cfg is
> needed. There should be no need to keep these two "in sync" with
> only mon_evt::evt_cfg as the source of configuration. I seem to be missing
> something here, could you please detail this scenario?

As discussed earlier, removed the following check. Return success if the
counter is assigned already.

https://lore.kernel.org/lkml/887bad33-7f4a-4b6d-95a7-fdfe0451f42b@intel.com/

> 
>> +	 */
>> +	if (mevt->evt_cfg != d->cntr_cfg[cntr_id].evt_cfg) {
>> +		d->cntr_cfg[cntr_id].evt_cfg = mevt->evt_cfg;
>> +		resctrl_config_cntr(r, d, mevt->evtid, rdtgrp->mon.rmid,
>> +				    rdtgrp->closid, cntr_id, true);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * resctrl_assign_cntr_event() - Assign a hardware counter for the event in
>> + * @mevt to the resctrl group @rdtgrp. Assign counters to all domains if @d is
>> + * NULL; otherwise, assign the counter to the specified domain @d.
>> + *
>> + * If all counters in a domain are already in use, resctrl_alloc_config_cntr()
>> + * will fail. The assignment process will abort at the first failure encountered
>> + * during domain traversal, which may result in the event being only partially
>> + * assigned.
>> + *
>> + * Return:
>> + * 0 on success, or a non-zero value on failure.
> 
> "or a non-zero value on failure" -> "<0 on failure"
> 

Sure.

>> + */
>> +int resctrl_assign_cntr_event(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +			      struct rdtgroup *rdtgrp, struct mon_evt *mevt)
>> +{
>> +	int ret = 0;
>> +
>> +	if (!d) {
>> +		list_for_each_entry(d, &r->mon_domains, hdr.list) {
>> +			ret = resctrl_alloc_config_cntr(r, d, rdtgrp, mevt);
>> +			if (ret)
>> +				return ret;
>> +		}
>> +	} else {
>> +		ret = resctrl_alloc_config_cntr(r, d, rdtgrp, mevt);
>> +	}
>> +
>> +	return ret;
>> +}
> 
> Reinette
> 

-- 
Thanks
Babu Moger

  reply	other threads:[~2025-06-26 19:32 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13 21:04 [PATCH v14 00/32] fs,x86/resctrl: Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2025-06-13 21:04 ` [PATCH v14 01/32] x86,fs/resctrl: Remove unappropriate references to cacheinfo in the resctrl subsystem Babu Moger
2025-06-13 21:04 ` [PATCH v14 02/32] x86,fs/resctrl: Consolidate monitor event descriptions Babu Moger
2025-06-24 21:28   ` Reinette Chatre
2025-06-25 15:57     ` Moger, Babu
2025-06-25 17:55       ` Luck, Tony
2025-06-25 20:12         ` Luck, Tony
2025-06-25 22:31           ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 03/32] x86,fs/resctrl: Replace architecture event enabled checks Babu Moger
2025-06-13 21:04 ` [PATCH v14 04/32] x86/resctrl: Remove 'rdt_mon_features' global variable Babu Moger
2025-06-13 21:04 ` [PATCH v14 05/32] x86,fs/resctrl: Prepare for more monitor events Babu Moger
2025-06-24 21:30   ` Reinette Chatre
2025-06-13 21:04 ` [PATCH v14 06/32] x86/cpufeatures: Add support for Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2025-06-24 21:31   ` Reinette Chatre
2025-06-25 16:28     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 07/32] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2025-06-13 21:04 ` [PATCH v14 08/32] x86,fs/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2025-06-24 21:32   ` Reinette Chatre
2025-06-25 16:53     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 09/32] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2025-06-24 21:33   ` Reinette Chatre
2025-06-25 17:58     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 10/32] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2025-06-24 22:37   ` Reinette Chatre
2025-06-25 19:50     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 11/32] fs/resctrl: Introduce the interface to display monitoring modes Babu Moger
2025-06-24 22:47   ` Reinette Chatre
2025-06-25 20:14     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 12/32] fs/resctrl: Introduce interface to display number of assignable counter IDs Babu Moger
2025-06-24 23:05   ` Reinette Chatre
2025-06-25 20:33     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 13/32] fs/resctrl: Introduce mbm_cntr_cfg to track assignable counters per domain Babu Moger
2025-06-24 23:31   ` Reinette Chatre
2025-06-26  1:31     ` Moger, Babu
2025-06-26 15:05       ` Reinette Chatre
2025-06-26 15:46         ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 14/32] fs/resctrl: Introduce interface to display number of free MBM counters Babu Moger
2025-06-24 23:39   ` Reinette Chatre
2025-06-26 14:17     ` Moger, Babu
2025-06-24 23:41   ` Reinette Chatre
2025-06-26 14:19     ` Moger, Babu
2025-06-13 21:04 ` [PATCH v14 15/32] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2025-06-13 21:05 ` [PATCH v14 16/32] x86,fs/resctrl: Introduce event configuration field in struct mon_evt Babu Moger
2025-06-24 23:51   ` Reinette Chatre
2025-06-26 16:47     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 17/32] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC Babu Moger
2025-06-25  3:03   ` Reinette Chatre
2025-06-26 17:41     ` Moger, Babu
2025-06-26 18:02       ` Reinette Chatre
2025-06-26 18:35         ` Moger, Babu
2025-06-26 20:24           ` Reinette Chatre
2025-06-13 21:05 ` [PATCH v14 18/32] fs/resctrl: Add the functionality to assign MBM events Babu Moger
2025-06-25  3:32   ` Reinette Chatre
2025-06-26 19:31     ` Moger, Babu [this message]
2025-06-13 21:05 ` [PATCH v14 19/32] fs/resctrl: Add the functionality to unassign " Babu Moger
2025-06-25  3:38   ` Reinette Chatre
2025-06-26 21:12     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 20/32] fs/resctrl: Report 'Unassigned' for MBM events in mbm_event mode Babu Moger
2025-06-25  4:14   ` Reinette Chatre
2025-06-27  1:34     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 21/32] fs/resctrl: Pass entire struct rdtgroup rather than passing individual members Babu Moger
2025-06-25  4:18   ` Reinette Chatre
2025-06-30 13:57     ` Moger, Babu
2025-06-30 15:44       ` Reinette Chatre
2025-06-30 20:58         ` Moger, Babu
2025-06-30 21:59           ` Reinette Chatre
2025-06-30 22:47             ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 22/32] x86,fs/resctrl: Add the support for reading ABMC counters Babu Moger
2025-06-13 21:05 ` [PATCH v14 23/32] fs/resctrl: Add definitions for MBM event configuration Babu Moger
2025-06-25  4:32   ` Reinette Chatre
2025-06-30 17:20     ` Moger, Babu
2025-06-30 21:58       ` Reinette Chatre
2025-06-30 22:51         ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 24/32] fs/resctrl: Add event configuration directory under info/L3_MON/ Babu Moger
2025-06-25 23:23   ` Reinette Chatre
2025-06-30 19:06     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 25/32] fs/resctrl: Provide interface to update the event configurations Babu Moger
2025-06-25 23:21   ` Reinette Chatre
2025-07-01  0:43     ` Moger, Babu
2025-07-01  1:33       ` Reinette Chatre
2025-07-01 16:14         ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 26/32] fs/resctrl: Introduce mbm_assign_on_mkdir to enable assignments on mkdir Babu Moger
2025-06-25 23:24   ` Reinette Chatre
2025-07-01 16:23     ` Moger, Babu
2025-07-01 16:37       ` Reinette Chatre
2025-06-13 21:05 ` [PATCH v14 27/32] x86,fs/resctrl: Auto assign/unassign counters " Babu Moger
2025-06-25 23:25   ` Reinette Chatre
2025-07-01 19:06     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 28/32] fs/resctrl: Introduce mbm_L3_assignments to list assignments in a group Babu Moger
2025-06-25 23:27   ` Reinette Chatre
2025-07-01 19:48     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 29/32] fs/resctrl: Introduce the interface to modify " Babu Moger
2025-06-25 23:38   ` Reinette Chatre
2025-07-02  2:18     ` Moger, Babu
2025-07-02  2:56       ` Reinette Chatre
2025-06-13 21:05 ` [PATCH v14 30/32] fs/resctrl: Hide the BMEC related files when mbm_event mode is enabled Babu Moger
2025-06-25 23:39   ` Reinette Chatre
2025-07-02 16:42     ` Moger, Babu
2025-07-02 17:21       ` Reinette Chatre
2025-07-02 19:04         ` Moger, Babu
2025-07-03 16:21           ` Reinette Chatre
2025-07-07 22:35             ` Moger, Babu
2025-07-08 13:27               ` Moger, Babu
2025-07-08 15:21                 ` Reinette Chatre
2025-07-08 15:43                   ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 31/32] fs/resctrl: Introduce the interface to switch between monitor modes Babu Moger
2025-06-25 23:40   ` Reinette Chatre
2025-07-02 17:39     ` Moger, Babu
2025-06-13 21:05 ` [PATCH v14 32/32] x86/resctrl: Configure mbm_event mode if supported Babu Moger
2025-06-25 23:40   ` Reinette Chatre
2025-07-02 17:45     ` Moger, Babu
2025-06-13 21:41 ` [PATCH v14 00/32] fs,x86/resctrl: Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Luck, Tony
2025-06-16 14:47   ` Moger, Babu
2025-06-24 21:25 ` Reinette Chatre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95e675a6-5cec-4f14-bb57-eebffb6024a5@amd.com \
    --to=babu.moger@amd.com \
    --cc=Dave.Martin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=eranian@google.com \
    --cc=fenghuay@nvidia.com \
    --cc=gautham.shenoy@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=kai.huang@intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=manali.shukla@amd.com \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=perry.yuan@amd.com \
    --cc=peternewman@google.com \
    --cc=peterz@infradead.org \
    --cc=reinette.chatre@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=thuth@redhat.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=xin3.li@intel.com \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®