mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Babu Moger <babu.moger@amd.com>, <tony.luck@intel.com>,
	<peternewman@google.com>
Cc: <corbet@lwn.net>, <tglx@linutronix.de>, <mingo@redhat.com>,
	<bp@alien8.de>, <dave.hansen@linux.intel.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>, <maciej.wieczor-retman@intel.com>,
	<eranian@google.com>
Subject: Re: [PATCH v12 14/26] x86/resctrl: Add the functionality to assign MBM events
Date: Fri, 11 Apr 2025 14:04:47 -0700	[thread overview]
Message-ID: <59fbd325-04e8-459f-a724-ae0c4536b1a5@intel.com> (raw)
In-Reply-To: <22889d46484b2393d701ce83c82f253c1454216b.1743725907.git.babu.moger@amd.com>

Hi Babu,

On 4/3/25 5:18 PM, Babu Moger wrote:
> The mbm_cntr_assign mode offers "num_mbm_cntrs" number of counters that
> can be assigned to an RMID, event pair and monitor the bandwidth as long
> as it is assigned.

Above makes it sound as though multiple counters can be assigned to
an RMID, event pair.

> 
> Add the functionality to allocate and assign the counters to RMID, event
> pair in the domain.

"assign *a* counter to an RMID, event pair"?

> 
> If all the counters are in use, the 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>
> ---

...

> ---
>  arch/x86/kernel/cpu/resctrl/internal.h |   2 +
>  arch/x86/kernel/cpu/resctrl/monitor.c  | 124 +++++++++++++++++++++++++
>  2 files changed, 126 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index 0b73ec451d2c..1a8ac511241a 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -574,6 +574,8 @@ bool closid_allocated(unsigned int closid);
>  int resctrl_find_cleanest_closid(void);
>  void arch_mbm_evt_config_init(struct rdt_hw_mon_domain *hw_dom);
>  unsigned int mon_event_config_index_get(u32 evtid);
> +int resctrl_assign_cntr_event(struct rdt_resource *r, struct rdt_mon_domain *d,
> +			      struct rdtgroup *rdtgrp, enum resctrl_event_id evtid, u32 evt_cfg);

This is internal to resctrl fs. Why is it needed to provide both the event id
and the event configuration? Event configuration can be determined from event ID?

>  
>  #ifdef CONFIG_RESCTRL_FS_PSEUDO_LOCK
>  int rdtgroup_locksetup_enter(struct rdtgroup *rdtgrp);
> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
> index 77f8662dc50b..ff55a4fe044f 100644
> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
> @@ -1469,3 +1469,127 @@ int resctrl_arch_config_cntr(struct rdt_resource *r, struct rdt_mon_domain *d,
>  
>  	return 0;
>  }
> +
> +/*
> + * Configure the counter for the event, RMID pair for the domain. Reset the
> + * non-architectural state to clear all the event counters.
> + */
> +static int 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;
> +	int ret;
> +
> +	ret = resctrl_arch_config_cntr(r, d, evtid, rmid, closid, cntr_id, evt_cfg, assign);
> +	if (ret)
> +		return ret;

I understood previous discussion to conclude that resctrl_arch_config_cntr() cannot fail
and thus I expect it to return void and not need any error checking from caller.
By extension this will result in resctrl_config_cntr() returning void and should simplify
a few flows. For example, it will make it clear that re-configuring an existing counter
cannot result in that counter being freed.

> +
> +	m = get_mbm_state(d, closid, rmid, evtid);
> +	if (m)
> +		memset(m, 0, sizeof(struct mbm_state));
> +
> +	return ret;
> +}
> +

Could you please add comments to these mbm_cntr* functions to provide information
on how the cntr_cfg data structure is used? Please also include details on
callers since it seems to me as though these functions are called
from paths where assignable counters are not supported (mon_event_read()).

> +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;
> +
> +	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;
> +}
> +
> +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;
> +}
> +
> +static void mbm_cntr_free(struct rdt_mon_domain *d, int cntr_id)
> +{
> +	memset(&d->cntr_cfg[cntr_id], 0, sizeof(struct mbm_cntr_cfg));
> +}
> +
> +/*
> + * 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,
> +				     u32 evt_cfg)

Same here, why are both evtid and evt_cfg provided as arguments? 

> +{
> +	int cntr_id, ret = 0;
> +
> +	/*
> +	 * No need to allocate or configure if the counter is already assigned
> +	 * and the event configuration is up to date.
> +	 */
> +	cntr_id = mbm_cntr_get(r, d, rdtgrp, evtid);
> +	if (cntr_id >= 0) {
> +		if (d->cntr_cfg[cntr_id].evt_cfg == evt_cfg)
> +			return 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);

Please print resource name also.

> +		return cntr_id;
> +	}
> +
> +cntr_configure:
> +	/* Update and configure the domain with the new event configuration value */
> +	d->cntr_cfg[cntr_id].evt_cfg = evt_cfg;
> +
> +	ret = resctrl_config_cntr(r, d, evtid, rdtgrp->mon.rmid, rdtgrp->closid,
> +				  cntr_id, evt_cfg, true);
> +	if (ret) {
> +		rdt_last_cmd_printf("Assignment of event %d failed on domain %d\n",
> +				    evtid, d->hdr.id);

How is user expected to interpret the event ID (especially when looking forward
where events can be dynamic)? This should rather be the event name.

> +		mbm_cntr_free(d, cntr_id);
> +	}
> +
> +	return ret;
> +}
> +
> +/*
> + * Assign a hardware counter to event @evtid of group @rdtgrp. Counter will be
> + * assigned to all the domains if @d is NULL else the counter will be assigned
> + * to @d.
> + */
> +int resctrl_assign_cntr_event(struct rdt_resource *r, struct rdt_mon_domain *d,
> +			      struct rdtgroup *rdtgrp, enum resctrl_event_id evtid,
> +			      u32 evt_cfg)
> +{
> +	int ret = 0;
> +
> +	if (!d) {
> +		list_for_each_entry(d, &r->mon_domains, hdr.list) {
> +			ret = resctrl_alloc_config_cntr(r, d, rdtgrp, evtid, evt_cfg);
> +			if (ret)
> +				return ret;
> +		}
> +	} else {
> +		ret = resctrl_alloc_config_cntr(r, d, rdtgrp, evtid, evt_cfg);
> +	}
> +
> +	return ret;
> +}

Reinette

  reply	other threads:[~2025-04-11 21:04 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04  0:18 [PATCH v12 00/26] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2025-04-04  0:18 ` [PATCH v12 01/26] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg in struct rdt_hw_mon_domain Babu Moger
2025-04-11 20:49   ` Reinette Chatre
2025-04-14 15:56     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 02/26] x86/resctrl: Remove MSR reading of event configuration value Babu Moger
2025-04-11 20:50   ` Reinette Chatre
2025-04-14 15:57     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 03/26] x86/cpufeatures: Add support for Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2025-04-11 20:52   ` Reinette Chatre
2025-04-14 17:48     ` Moger, Babu
2025-04-15 16:09       ` Reinette Chatre
2025-04-15 19:43         ` Moger, Babu
2025-04-16 16:08           ` Reinette Chatre
2025-04-17 14:27             ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 04/26] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2025-04-04  0:18 ` [PATCH v12 05/26] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2025-04-04  0:18 ` [PATCH v12 06/26] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2025-04-04  0:18 ` [PATCH v12 07/26] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2025-04-04  0:18 ` [PATCH v12 08/26] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2025-04-11 20:56   ` Reinette Chatre
2025-04-14 19:52     ` Moger, Babu
2025-04-15 16:22       ` Reinette Chatre
2025-04-16 14:05         ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 09/26] x86/resctrl: Introduce interface to display number of monitoring counters Babu Moger
2025-04-11 21:01   ` Reinette Chatre
2025-04-14 20:12     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 10/26] x86/resctrl: Introduce mbm_cntr_cfg to track assignable counters at domain Babu Moger
2025-04-04  0:18 ` [PATCH v12 11/26] x86/resctrl: Introduce interface to display number of free MBM counters Babu Moger
2025-04-04  0:18 ` [PATCH v12 12/26] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2025-04-11 21:01   ` Reinette Chatre
2025-04-14 20:30     ` Moger, Babu
2025-04-15 16:30       ` Reinette Chatre
2025-04-16 15:43         ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 13/26] x86/resctrl: Implement resctrl_arch_config_cntr() to assign a counter with ABMC Babu Moger
2025-04-11 21:02   ` Reinette Chatre
2025-04-14 20:51     ` Moger, Babu
2025-04-15 16:38       ` Reinette Chatre
2025-04-16 15:51         ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 14/26] x86/resctrl: Add the functionality to assign MBM events Babu Moger
2025-04-11 21:04   ` Reinette Chatre [this message]
2025-04-15 14:20     ` Moger, Babu
2025-04-15 16:53       ` Reinette Chatre
2025-04-16 17:09         ` Moger, Babu
2025-04-16 17:55           ` Luck, Tony
2025-04-16 18:17             ` Moger, Babu
2025-04-16 19:02           ` Reinette Chatre
2025-04-16 19:29             ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 15/26] x86/resctrl: Add the functionality to unassign " Babu Moger
2025-04-04  0:18 ` [PATCH v12 16/26] x86/resctrl: Report 'Unassigned' for MBM events in mbm_cntr_assign mode Babu Moger
2025-04-11 21:08   ` Reinette Chatre
2025-04-15 15:00     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 17/26] x86/resctrl: Add the support for reading ABMC counters Babu Moger
2025-04-11 21:21   ` Reinette Chatre
2025-04-15 16:41     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 18/26] x86/resctrl: Add default MBM event configurations for mbm_cntr_assign mode Babu Moger
2025-04-11 21:44   ` Reinette Chatre
2025-04-15 18:48     ` Moger, Babu
2025-04-15 19:25       ` Luck, Tony
2025-04-16 16:21         ` Reinette Chatre
2025-04-16 17:26           ` Moger, Babu
2025-04-16 16:18       ` Reinette Chatre
2025-04-16 17:27         ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 19/26] x86/resctrl: Add event configuration directory under info/L3_MON/ Babu Moger
2025-04-11 22:04   ` Reinette Chatre
2025-04-15 20:29     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 20/26] x86/resctrl: Provide interface to update the event configurations Babu Moger
2025-04-11 22:07   ` Reinette Chatre
2025-04-15 20:37     ` Moger, Babu
2025-04-16 18:52       ` Reinette Chatre
2025-04-17 14:34         ` Moger, Babu
2025-04-17 15:09           ` Reinette Chatre
2025-04-17 20:19             ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 21/26] x86/resctrl: Introduce mbm_assign_on_mkdir to configure assignments Babu Moger
2025-04-11 22:08   ` Reinette Chatre
2025-04-15 20:39     ` Moger, Babu
2025-04-04  0:18 ` [PATCH v12 22/26] x86/resctrl: Auto assign/unassign counters when mbm_cntr_assign is enabled Babu Moger
2025-04-04  0:18 ` [PATCH v12 23/26] x86/resctrl: Introduce mbm_L3_assignments to list assignments in a group Babu Moger
2025-04-04  0:18 ` [PATCH v12 24/26] x86/resctrl: Introduce the interface to modify " Babu Moger
2025-04-04  0:18 ` [PATCH v12 25/26] x86/resctrl: Introduce the interface to switch between monitor modes Babu Moger
2025-04-04  0:18 ` [PATCH v12 26/26] x86/resctrl: Configure mbm_cntr_assign mode if supported Babu Moger

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=59fbd325-04e8-459f-a724-ae0c4536b1a5@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel.sneddon@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebiggers@google.com \
    --cc=eranian@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.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=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®