patches.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Tony Luck <tony.luck@intel.com>, Fenghua Yu <fenghuay@nvidia.com>,
	"Maciej Wieczor-Retman" <maciej.wieczor-retman@intel.com>,
	Peter Newman <peternewman@google.com>,
	James Morse <james.morse@arm.com>,
	Babu Moger <babu.moger@amd.com>,
	Drew Fustini <dfustini@baylibre.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Anil Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	Chen Yu <yu.c.chen@intel.com>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
	<patches@lists.linux.dev>
Subject: Re: [PATCH v4 18/31] x86/resctrl: Add third part of telemetry event enumeration
Date: Thu, 8 May 2025 08:56:15 -0700	[thread overview]
Message-ID: <1d54ec15-8c07-4d6a-ad8b-72c376389b48@intel.com> (raw)
In-Reply-To: <20250429003359.375508-19-tony.luck@intel.com>

Hi Tony,

On 4/28/25 5:33 PM, Tony Luck wrote:
> Counters for telemetry events are in MMIO space. Each telemetry_region
> structure returned in the pmt_feature_group returned from OOBMSM
> contains the base MMIO address for the counters.
> 
> Scan all the telemetry_region structures again and gather these
> addresses into a more convenient structure with addresses for
> each aggregator indexed by package id. Note that there may be
> multiple aggregators per package.

Could this series please provide a clear definition for "telemetry
region" and "aggregator" and then use the terms consistently?
I find the comments to switch between the two causing confusion.

> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
>  arch/x86/kernel/cpu/resctrl/intel_aet.c | 55 +++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/resctrl/intel_aet.c b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> index a0365c3ce982..03839d5c369b 100644
> --- a/arch/x86/kernel/cpu/resctrl/intel_aet.c
> +++ b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> @@ -20,6 +20,16 @@
>  
>  #include "internal.h"
>  
> +/**
> + * struct mmio_info - Array of MMIO addresses for a package

Please add description on how this structure is used. Please use
these docs to help readers create a mental model of how these
data structures fit together. 

I am making an attempt at an example below but I am still trying to
understand how things fit together so would appreciate if you
write this instead. (Please consider this when viewing any of the
samples I provide.)

Example,
	Array of MMIO addresses of one event group for a package.

	Provides convenient access to all MMIO addresses of
	one event group for one package. Used when reading
	event data on a package. (needs improvement)

> + * @count:		Number of addresses on this package

Any information on what this number means? For example,
"Number of telemetry regions of a specific event group."

> + * @addrs:		The MMIO addresses

Can the layout of MMIO space be added to the comments? 

> + */
> +struct mmio_info {
> +	int		count;
> +	void __iomem	*addrs[] __counted_by(count);
> +};
> +
>  /**
>   * struct event_group - All information about a group of telemetry events.
>   *                      Some fields initialized with MMIO layout information
> @@ -27,10 +37,12 @@
>   *                      retrieved from intel_pmt_get_regions_by_feature().
>   * @pfg:		The pmt_feature_group for this event group
>   * @guid:		Unique number per XML description file
> + * @pkginfo:		Per-package MMIO addresses

"Per-package MMIO addresses of telemetry regions belonging to this group."?

>   */
>  struct event_group {
>  	struct pmt_feature_group	*pfg;
>  	int				guid;
> +	struct mmio_info		**pkginfo;
>  };
>  
>  /* Link: https://github.com/intel/Intel-PMT xml/CWF/OOBMSM/RMID-ENERGY *.xml */
> @@ -50,12 +62,33 @@ static struct event_group *known_event_groups[] = {
>  
>  #define NUM_KNOWN_GROUPS ARRAY_SIZE(known_event_groups)
>  
> +static void free_mmio_info(struct mmio_info **mmi)
> +{
> +	int num_pkgs = topology_max_packages();
> +
> +	if (!mmi)
> +		return;
> +
> +	for (int i = 0; i < num_pkgs; i++)
> +		kfree(mmi[i]);
> +	kfree(mmi);
> +}
> +
> +DEFINE_FREE(mmio_info, struct mmio_info **, free_mmio_info(_T))
> +
>  static bool configure_events(struct event_group *e, struct pmt_feature_group *p)
>  {
> +	struct mmio_info __free(mmio_info) **pkginfo = NULL;
>  	int *pkgcounts __free(kfree) = NULL;
>  	struct telemetry_region *tr;
> +	struct mmio_info *mmi;
>  	int num_pkgs;
>  
> +	if (e->pkginfo) {
> +		pr_warn("Duplicate telemetry information for guid 0x%x\n", e->guid);
> +		return false;
> +	}
> +
>  	num_pkgs = topology_max_packages();
>  	pkgcounts = kcalloc(num_pkgs, sizeof(*pkgcounts), GFP_KERNEL);
>  	if (!pkgcounts)
> @@ -73,6 +106,27 @@ static bool configure_events(struct event_group *e, struct pmt_feature_group *p)
>  		pkgcounts[tr->plat_info.package_id]++;
>  	}
>  
> +	/* Allocate per-package arrays and save MMIO addresses */

per-package arrays of what?

> +	pkginfo = kcalloc(num_pkgs, sizeof(*pkginfo), GFP_KERNEL);
> +	if (!pkginfo)
> +		return false;

-ENOMEM

> +	for (int i = 0; i < num_pkgs; i++) {
> +		pkginfo[i] = kmalloc(struct_size(pkginfo[i], addrs, pkgcounts[i]), GFP_KERNEL);

kzalloc()

> +		if (!pkginfo[i])
> +			return false;

-ENOMEM

> +		pkginfo[i]->count = pkgcounts[i];
> +	}
> +
> +	/* Save MMIO address(es) for each aggregator in per-package structures */

Should "aggregator" be "telemetry region"? It is becoming confusing what "aggregator"
vs "telemetry region" represents here.

> +	for (int i = 0; i < p->count; i++) {
> +		tr = &p->regions[i];
> +		if (tr->guid != e->guid || tr->plat_info.package_id >= num_pkgs)
> +			continue;
> +		mmi = pkginfo[tr->plat_info.package_id];
> +		mmi->addrs[--pkgcounts[tr->plat_info.package_id]] = tr->addr;

For this code to be safe the "if()" checks that precede it must match *exactly*
with the checks used to initialize the pkgcounts array. To ensure this remains the
case I think those checks need to be placed in a function to be called in both
places.

> +	}
> +	e->pkginfo = no_free_ptr(pkginfo);
> +
>  	return false;
>  }
>  
> @@ -130,5 +184,6 @@ void __exit intel_aet_exit(void)
>  			intel_pmt_put_feature_group((*peg)->pfg);
>  			(*peg)->pfg = NULL;
>  		}
> +		free_mmio_info((*peg)->pkginfo);
>  	}
>  }

Reinette

  reply	other threads:[~2025-05-08 15:56 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-29  0:33 [PATCH v4 00/31] x86/resctrl telemetry monitoring Tony Luck
2025-04-29  0:33 ` [PATCH v4 01/31] x86,fs/resctrl: Drop rdt_mon_features variable Tony Luck
2025-05-08  3:28   ` Reinette Chatre
2025-05-08 18:32     ` Luck, Tony
2025-05-08 23:44       ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 02/31] x86,fs/resctrl: Prepare for more monitor events Tony Luck
2025-05-08  3:30   ` Reinette Chatre
2025-05-09 15:02   ` Peter Newman
2025-04-29  0:33 ` [PATCH v4 03/31] fs/resctrl: Clean up rdtgroup_mba_mbps_event_{show,write}() Tony Luck
2025-05-08  3:31   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 04/31] fs/resctrl: Change how and when events are initialized Tony Luck
2025-05-08  3:31   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 05/31] fs/resctrl: Set up Kconfig options for telemetry events Tony Luck
2025-05-08  3:32   ` Reinette Chatre
2025-05-10  9:58   ` Chen, Yu C
2025-05-12 14:19     ` Luck, Tony
2025-04-29  0:33 ` [PATCH v4 06/31] x86/rectrl: Fake OOBMSM interface Tony Luck
2025-04-30 23:02   ` Luck, Tony
2025-05-08  3:33   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 07/31] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-05-08  3:36   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 08/31] x86/resctrl: Move L3 initialization out of domain_add_cpu_mon() Tony Luck
2025-05-08  3:37   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 09/31] x86,fs/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-05-08  3:37   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 10/31] x86/resctrl: Change generic monitor functions to use struct rdt_domain_hdr Tony Luck
2025-05-08  3:38   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 11/31] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-05-08  3:39   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 12/31] fs/resctrl: Improve handling for events that can be read from any CPU Tony Luck
2025-05-08  3:54   ` Reinette Chatre
2025-05-13  3:19   ` Chen, Yu C
2025-05-13 16:20     ` Luck, Tony
2025-05-14  9:11       ` Chen, Yu C
2025-04-29  0:33 ` [PATCH v4 13/31] fs/resctrl: Add support for additional monitor event display formats Tony Luck
2025-05-08 15:49   ` Reinette Chatre
2025-05-08 20:28     ` Luck, Tony
2025-05-08 23:45       ` Reinette Chatre
2025-05-09 11:29         ` Dave Martin
2025-05-09 14:46           ` Peter Newman
2025-05-09 16:38             ` Luck, Tony
2025-05-09 16:43             ` Dave Martin
2025-04-29  0:33 ` [PATCH v4 14/31] fs/resctrl: Add an architectural hook called for each mount Tony Luck
2025-05-08 15:50   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 15/31] x86/resctrl: Add and initialize rdt_resource for package scope core monitor Tony Luck
2025-05-08 15:50   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 16/31] x86/resctrl: Add first part of telemetry event enumeration Tony Luck
2025-05-08 15:53   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 17/31] x86/resctrl: Add second " Tony Luck
2025-05-08 15:54   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 18/31] x86/resctrl: Add third " Tony Luck
2025-05-08 15:56   ` Reinette Chatre [this message]
2025-04-29  0:33 ` [PATCH v4 19/31] x86,fs/resctrl: Fill in details of Clearwater Forest events Tony Luck
2025-05-08 15:54   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 20/31] x86/resctrl: Check for adequate MMIO space Tony Luck
2025-05-08 15:56   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 21/31] x86/resctrl: Add fourth part of telemetry event enumeration Tony Luck
2025-05-08 15:56   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 22/31] x86/resctrl: Read core telemetry events Tony Luck
2025-05-08 15:57   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 23/31] x86,fs/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-05-08 15:58   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 24/31] fs/resctrl: Add type define for PERF_PKG files Tony Luck
2025-04-29  0:33 ` [PATCH v4 25/31] x86/resctrl: Final steps to enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-04-29  0:33 ` [PATCH v4 26/31] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2025-05-08 15:58   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 27/31] x86/resctrl: Handle number of RMIDs supported by telemetry resources Tony Luck
2025-05-08 15:59   ` Reinette Chatre
2025-04-29  0:33 ` [PATCH v4 28/31] x86,fs/resctrl: Fix RMID allocation for multiple monitor resources Tony Luck
2025-04-29  0:33 ` [PATCH v4 29/31] fs/resctrl: Add interface for per-resource debug info files Tony Luck
2025-04-29  0:33 ` [PATCH v4 30/31] x86/resctrl: Add info/PERF_PKG_MON/status file Tony Luck
2025-04-29  0:33 ` [PATCH v4 31/31] x86/resctrl: Update Documentation for package events Tony Luck

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=1d54ec15-8c07-4d6a-ad8b-72c376389b48@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=babu.moger@amd.com \
    --cc=dfustini@baylibre.com \
    --cc=fenghuay@nvidia.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=patches@lists.linux.dev \
    --cc=peternewman@google.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.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;
as well as URLs for NNTP newsgroup(s).