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
next prev parent 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).