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, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: james.morse@arm.com, dave.martin@arm.com, fenghuay@nvidia.com,
	x86@kernel.org, hpa@zytor.com, paulmck@kernel.org,
	akpm@linux-foundation.org, thuth@redhat.com, rostedt@goodmis.org,
	ardb@kernel.org, gregkh@linuxfoundation.org,
	daniel.sneddon@linux.intel.com, jpoimboe@kernel.org,
	alexandre.chartre@oracle.com, pawan.kumar.gupta@linux.intel.com,
	thomas.lendacky@amd.com, perry.yuan@amd.com, seanjc@google.com,
	kai.huang@intel.com, xiaoyao.li@intel.com,
	kan.liang@linux.intel.com, xin3.li@intel.com,
	ebiggers@google.com, xin@zytor.com, sohil.mehta@intel.com,
	andrew.cooper3@citrix.com, mario.limonciello@amd.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	peternewman@google.com, maciej.wieczor-retman@intel.com,
	eranian@google.com, Xiaojian.Du@amd.com, gautham.shenoy@amd.com
Subject: Re: [PATCH v13 13/27] x86/resctrl: Add the functionality to assign MBM events
Date: Thu, 29 May 2025 11:05:16 -0500	[thread overview]
Message-ID: <dfc593f2-b0e6-4946-9dcd-c5f3986c9e6c@amd.com> (raw)
In-Reply-To: <9b38056d-c0f3-4e28-87e4-413225fee91e@intel.com>

Hi Reinette,

On 5/22/25 17:41, Reinette Chatre wrote:
> Hi Babu,
> 
> On 5/15/25 3:51 PM, Babu Moger wrote:
>> The mbm_cntr_assign mode offers "num_mbm_cntrs" number of counters that
>> can be assigned to RMID, event pair and monitor the bandwidth as long
> 
> "RMID, event pairs"? (assuming at this point in new version it will be
> obvious what is meant by "event").

Sure.

> 
>> as it is assigned.
>>
>> Add the functionality to allocate and assign a counter to am RMID, event
> 
> "am" -> "an"
> 

sure.

>> 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 0fae374559ba..ce4fcac91937 100644
>> --- a/fs/resctrl/internal.h
>> +++ b/fs/resctrl/internal.h
>> @@ -377,6 +377,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, enum resctrl_event_id evtid);
>> +
>>  #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 8e403587a02f..d76fd0840946 100644
>> --- a/fs/resctrl/monitor.c
>> +++ b/fs/resctrl/monitor.c
>> @@ -934,3 +934,137 @@ void resctrl_mon_resource_exit(void)
>>  
>>  	dom_data_exit(r);
>>  }
>> +
>> +/*
>> + * Configure the counter for the event, RMID pair for the domain. Reset the
>> + * non-architectural state to clear all the event counters.
> 
> clear *all* the event counters?
> 
> "Reset the non-architectural state to clear all the event counters." ->
> "Reset the associated non-architectural state."?

ok.

> 
> Also, please see https://lore.kernel.org/lkml/20250429003359.375508-3-tony.luck@intel.com/

Yes. 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, u32 evt_cfg, bool assign)
>> +{
>> +	struct mbm_state *m;
>> +
>> +	resctrl_arch_config_cntr(r, d, evtid, rmid, closid, cntr_id, evt_cfg, assign);
>> +
>> +	m = get_mbm_state(d, closid, rmid, evtid);
>> +	if (m)
>> +		memset(m, 0, sizeof(struct mbm_state));
>> +}
>> +
>> +/*
>> + * mbm_cntr_get() - Return the cntr_id for the matching evtid and rdtgrp in
>> + *		    cntr_cfg array.
> 
> Please prefix parameter names with @ in description to make obvious what is
> refered to. Although "cntr_id" is a local variable so may be easier to parse
> if cntr_id is replaced with actual "counter ID" term while keeping rest as
> actual parameters. That makes cntr_cfg unneeded.

Sure.


> If intending to explain function context then failure return should also
> be documented. Even better would be to follow typical style of kernel-doc
> (even if not using /** start) and not mix and match so randomly.

Sure.

> 
>> + */
>> +static int mbm_cntr_get(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +			struct rdtgroup *rdtgrp, enum resctrl_event_id evtid)
>> +{
> 
> A subtle issue here is only evident from later patches, for example patch #17,
> that calls mbm_cntr_get() with a non MBM event ID from __mon_event_count().
> 
> If this usage is expected then these utilities needs extra checks to
> ensure they are only called with valid MBM event IDs.

Sure. Will add the check resctrl_is_mbm_event().

> 
>> +	int cntr_id;
>> +
>> +	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() - Return the first free entry in cntr_cfg array.
> 
> "Return the first ...array."  -> "Initilialize and return ID of a new counter, return -ENOSPC on failure." ?
> This is still an awkward use of kernel-doc ... better to be properly formatted.

Sure.

> 
>> + */
>> +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;
>> +}
>> +
>> +/*
>> + * mbm_get_mon_event() - Return the mon_evt entry for the matching evtid.
>> + */
>> +static struct mon_evt *mbm_get_mon_event(struct rdt_resource *r,
>> +					 enum resctrl_event_id evtid)
>> +{
>> +	struct mon_evt *mevt;
>> +
>> +	list_for_each_entry(mevt, &r->mon.evt_list, list) {
>> +		if (mevt->evtid == evtid)
>> +			return mevt;
>> +	}
> 
> With changes from  telemetry series this becomes an array lookup.

Sure. Will look into this.

> 
>> +
>> +	return NULL;
>> +}
>> +
>> +/*
>> + * Allocate a fresh counter and configure the event if not assigned already.
>> + */
>> +static int resctrl_alloc_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>> +				     struct rdtgroup *rdtgrp, enum resctrl_event_id evtid)
>> +{
>> +	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, evtid);
>> +	if (cntr_id >= 0)
>> +		goto cntr_configure;
>> +
>> +	cntr_id = mbm_cntr_alloc(r, d, rdtgrp, 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:
>> +	mevt = mbm_get_mon_event(r, evtid);
>> +	if (!mevt) {
>> +		rdt_last_cmd_printf("Invalid event id %d\n", evtid);
> 
> Difficult to see at this point but it seems that this is in kernel bug territory since
> user space provided text that is translated to event ID and here translated back to
> monitor event. This must succeed. Could this be simplified and back-and-forth avoided
> by passing the mon_evt instead of event ID?

We can do that.

> 
>> +		return -EINVAL;
>> +	}
> 
> 
> 
>> +
>> +	/*
>> +	 * Skip reconfiguration if the event setup is current; otherwise,
>> +	 * update and apply the new configuration to the domain.
>> +	 */
>> +	if (mevt->evt_cfg != d->cntr_cfg[cntr_id].evt_cfg) {
> 
> Lost me. Previous patch silently created mon_event::evt_cfg without initializing it.
> Here it is compared and treated as the "source of truth" ... where does its value
> come from?

Yes. That is correct. Will have to initialize evt_cfg when it is first
introduced. Will do.


> 
>> +		d->cntr_cfg[cntr_id].evt_cfg = mevt->evt_cfg;
>> +		resctrl_config_cntr(r, d, evtid, rdtgrp->mon.rmid, rdtgrp->closid,
>> +				    cntr_id, mevt->evt_cfg, true);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Assign a hardware counter to event @evtid of group @rdtgrp.
>> + * Assign counters to all domains if @d is NULL; otherwise, assign the
>> + * counter to the specified domain @d.
> 
> Can add here what is mentioned in changelog that this exits on first failure
> and so highlight that this can have partial assignment when exit on such failure.

Sure.

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

-- 
Thanks
Babu Moger

  reply	other threads:[~2025-05-29 16:05 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15 22:51 [PATCH v13 00/27] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2025-05-15 22:51 ` [PATCH v13 01/27] x86/cpufeatures: Add support for " Babu Moger
2025-05-22 20:51   ` Reinette Chatre
2025-05-27 17:23     ` Moger, Babu
2025-05-27 17:54       ` Reinette Chatre
2025-05-27 18:40         ` Moger, Babu
2025-05-27 23:42           ` Reinette Chatre
2025-05-28 16:18             ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 02/27] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2025-05-15 22:51 ` [PATCH v13 03/27] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2025-05-22 20:52   ` Reinette Chatre
2025-05-27 18:49     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 04/27] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2025-05-22 20:54   ` Reinette Chatre
2025-05-27 19:52     ` Moger, Babu
2025-05-27 20:15     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 05/27] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2025-05-22 20:56   ` Reinette Chatre
2025-05-27 20:21     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 06/27] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2025-05-22 20:56   ` Reinette Chatre
2025-05-27 20:33     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 07/27] x86/resctrl: Introduce interface to display number of monitoring counters Babu Moger
2025-05-15 22:51 ` [PATCH v13 08/27] x86/resctrl: Introduce mbm_cntr_cfg to track assignable counters at domain Babu Moger
2025-05-22 21:02   ` Reinette Chatre
2025-05-28 16:56     ` Moger, Babu
2025-05-28 17:34       ` Reinette Chatre
2025-05-28 19:05         ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 09/27] x86/resctrl: Introduce interface to display number of free MBM counters Babu Moger
2025-05-15 22:51 ` [PATCH v13 10/27] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2025-05-22 21:10   ` Reinette Chatre
2025-05-28 19:15     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 11/27] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC Babu Moger
2025-05-22 21:51   ` Reinette Chatre
2025-05-22 22:16     ` Luck, Tony
2025-05-23 21:08       ` Luck, Tony
2025-05-26 13:14         ` Peter Newman
2025-05-27 21:41           ` Luck, Tony
2025-05-28 21:41             ` Moger, Babu
2025-05-28 22:00               ` Luck, Tony
2025-05-28 22:13                 ` Luck, Tony
2025-05-28 23:48                   ` Moger, Babu
2025-06-09 14:01               ` Moger, Babu
2025-05-28 21:39     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 12/27] x86/resctrl: Introduce event configuration modes Babu Moger
2025-05-22 22:05   ` Reinette Chatre
2025-05-29 15:21     ` Moger, Babu
2025-05-15 22:51 ` [PATCH v13 13/27] x86/resctrl: Add the functionality to assign MBM events Babu Moger
2025-05-22 22:41   ` Reinette Chatre
2025-05-29 16:05     ` Moger, Babu [this message]
2025-05-15 22:51 ` [PATCH v13 14/27] x86/resctrl: Add the functionality to unassign " Babu Moger
2025-05-22 22:49   ` Reinette Chatre
2025-05-29 16:25     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 15/27] x86/resctrl: Report 'Unassigned' for MBM events in mbm_cntr_assign mode Babu Moger
2025-05-22 23:01   ` Reinette Chatre
2025-05-29 16:58     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 16/27] x86/resctrl: Pass entire struct rdtgroup rather than passing individual members Babu Moger
2025-05-22 23:05   ` Reinette Chatre
2025-05-29 18:07     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 17/27] x86/resctrl: Add the support for reading ABMC counters Babu Moger
2025-05-22 23:31   ` Reinette Chatre
2025-05-29 18:25     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 18/27] x86/resctrl: Add definitions for MBM event configuration Babu Moger
2025-05-23  4:41   ` Reinette Chatre
2025-05-29 19:00     ` Moger, Babu
2025-05-29 20:58       ` Reinette Chatre
2025-06-03 13:41         ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 19/27] x86/resctrl: Add event configuration directory under info/L3_MON/ Babu Moger
2025-05-23  4:43   ` Reinette Chatre
2025-05-29 19:54     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 20/27] x86/resctrl: Provide interface to update the event configurations Babu Moger
2025-05-23  4:45   ` Reinette Chatre
2025-05-29 22:35     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 21/27] x86/resctrl: Introduce mbm_assign_on_mkdir to configure assignments Babu Moger
2025-05-23  4:48   ` Reinette Chatre
2025-05-29 23:03     ` Moger, Babu
2025-05-30 20:54       ` Reinette Chatre
2025-06-03 14:00         ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 22/27] x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled Babu Moger
2025-05-15 22:52 ` [PATCH v13 23/27] x86/resctrl: Introduce mbm_L3_assignments to list assignments in a group Babu Moger
2025-05-23  4:47   ` Reinette Chatre
2025-05-30  0:55     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 24/27] x86/resctrl: Introduce the interface to modify " Babu Moger
2025-05-26  9:48   ` Peter Newman
2025-05-27 15:24     ` Moger, Babu
2025-05-15 22:52 ` [PATCH v13 25/27] x86/resctrl: Hide the BMEC related files when mbm_cnt_assign is enabled Babu Moger
2025-05-15 22:52 ` [PATCH v13 26/27] x86/resctrl: Introduce the interface to switch between monitor modes Babu Moger
2025-05-15 22:52 ` [PATCH v13 27/27] x86/resctrl: Configure mbm_cntr_assign mode if supported Babu Moger
2025-05-19 15:59 ` [PATCH v13 00/27] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Peter Newman
2025-05-20 15:28   ` Moger, Babu
2025-05-20 16:06     ` Reinette Chatre
2025-05-20 17:51       ` Moger, Babu
2025-05-20 18:23         ` Reinette Chatre
2025-05-20 23:25           ` Moger, Babu
2025-05-20 23:44             ` Reinette Chatre
2025-05-21  9:18               ` Peter Newman
2025-05-21 23:03                 ` Reinette Chatre
2025-05-21 23:43                   ` Luck, Tony
2025-05-22  0:10                     ` Reinette Chatre
2025-05-22  0:21                       ` Luck, Tony
2025-05-22  8:47                         ` Peter Newman
2025-05-22 16:32                           ` Reinette Chatre
2025-05-22 17:21                           ` Luck, Tony
2025-05-22 15:44                   ` Moger, Babu
2025-05-22 16:33                     ` Reinette Chatre
2025-05-22 19:15                       ` Moger, Babu
2025-06-10 23:19                       ` Moger, Babu
2025-06-11 18:29                         ` Reinette Chatre
2025-06-11 21:21                           ` Moger, Babu
2025-05-21 14:27               ` Peter Newman
2025-05-21 23:05                 ` Reinette Chatre
2025-05-22  9:14                   ` Peter Newman
2025-05-22 16:33                     ` Reinette Chatre
2025-05-22 20:44 ` 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=dfc593f2-b0e6-4946-9dcd-c5f3986c9e6c@amd.com \
    --to=babu.moger@amd.com \
    --cc=Xiaojian.Du@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel.sneddon@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.martin@arm.com \
    --cc=ebiggers@google.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=jpoimboe@kernel.org \
    --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=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=reinette.chatre@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.com \
    --cc=sohil.mehta@intel.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®