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 16/31] x86/resctrl: Add first part of telemetry event enumeration
Date: Thu, 8 May 2025 08:53:24 -0700 [thread overview]
Message-ID: <85c670f4-e34d-46da-8458-b7233a902a5f@intel.com> (raw)
In-Reply-To: <20250429003359.375508-17-tony.luck@intel.com>
Hi Tony,
After working with this series for a while and needing to jump between
patches to understand how things fit together I would like to please ask
that you replace these "Add <num> part ..." and "Final steps ..." shortlogs
with something descriptive that reflects what the patch actually does.
This will make it much easier to jump between patches while trying
to understand how this all fits together.
On 4/28/25 5:33 PM, Tony Luck wrote:
> The OOBMSM VSEC discovery driver enumerates many different types
> of telemetry resources. Resctrl is only interested in the ones
> that are tied to an RMID value in the IA32_PQR_ASSOC MSR.
"RMID value in the IA32_PQR_ASSOC MSR" -> "RMID value that can be used
in the IA32_PQR_ASSOC MSR"?
>
> Make a request for each of the FEATURE_PER_RMID_ENERGY_TELEM and
"for each of the" -> "for the"
> FEATURE_PER_RMID_PERF_TELEM feature groups and scan the list
> of known event groups for matching guid values.
This is the first (apart from fake driver) mention of guid and it
is mentioned in a way that assumes reader knows what it means and what
the significance is. Please add more context about what guid means/represents.
>
> Configuration to follow in subsequent patches.
Please avoid "subsequent patches" in changelog.
>
> Hold onto references to any pmt_feature_groups that resctrl
How is reader expected to know what a "pmt_feature_group" is?
This work relies on a new separate feature that introduces new
data structures and itself introduces several data structures.
Please help reader to understand how this all fits together.
> uses until resctrl exit.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
> arch/x86/kernel/cpu/resctrl/internal.h | 8 ++
> arch/x86/kernel/cpu/resctrl/core.c | 5 ++
> arch/x86/kernel/cpu/resctrl/intel_aet.c | 113 ++++++++++++++++++++++++
> arch/x86/kernel/cpu/resctrl/Makefile | 1 +
> 4 files changed, 127 insertions(+)
> create mode 100644 arch/x86/kernel/cpu/resctrl/intel_aet.c
>
> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> index 83b20e6b25d7..571db665eca6 100644
> --- a/arch/x86/kernel/cpu/resctrl/internal.h
> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> @@ -167,4 +167,12 @@ void __init intel_rdt_mbm_apply_quirk(void);
>
> void rdt_domain_reconfigure_cdp(struct rdt_resource *r);
>
> +#ifdef CONFIG_INTEL_AET_RESCTRL
> +bool intel_aet_get_events(void);
> +void __exit intel_aet_exit(void);
> +#else
> +static inline bool intel_aet_get_events(void) { return false; }
> +static inline void intel_aet_exit(void) { };
Extra semicolon?
> +#endif
> +
> #endif /* _ASM_X86_RESCTRL_INTERNAL_H */
> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> index 4d1556707c01..0103f577e4ca 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -724,6 +724,9 @@ void resctrl_arch_pre_mount(void)
>
> if (atomic_cmpxchg(&only_once, 0, 1))
> return;
> +
> + if (!intel_aet_get_events())
> + return;
> }
>
> enum {
> @@ -1076,6 +1079,8 @@ late_initcall(resctrl_arch_late_init);
>
> static void __exit resctrl_arch_exit(void)
> {
> + intel_aet_exit();
> +
> cpuhp_remove_state(rdt_online);
>
> resctrl_exit();
> diff --git a/arch/x86/kernel/cpu/resctrl/intel_aet.c b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> new file mode 100644
> index 000000000000..dda44baf75ae
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Resource Director Technology(RDT)
> + * - Intel Application Energy Telemetry
> + *
> + * Copyright (C) 2025 Intel Corporation
> + *
> + * Author:
> + * Tony Luck <tony.luck@intel.com>
> + */
> +
> +#define pr_fmt(fmt) "resctrl: " fmt
> +
> +#include <linux/cleanup.h>
> +#include <linux/cpu.h>
> +#include <linux/resctrl.h>
> +
> +/* Temporary - delete from final version */
> +#include "fake_intel_aet_features.h"
> +
> +#include "internal.h"
> +
> +/**
> + * struct event_group - All information about a group of telemetry events.
> + * Some fields initialized with MMIO layout information
> + * gleaned from the XML files. Others are set from data
> + * retrieved from intel_pmt_get_regions_by_feature().
Please see "Structure, union, and enumeration documentation" in
Documentation/doc-guide/kernel-doc.rst on how a "brief description" is
separate from the full description.
The "some" and "others" is quite vague. The members themselves
can have snippet to indicate where it is initialized from.
> + * @pfg: The pmt_feature_group for this event group
This comment does not add any information.
"Points to the aggregated telemetry space information within the OOBMSM driver
that contains data for all telemetry regions ..."
> + * @guid: Unique number per XML description file
How can it be sure that it is clear to reader what "XML description file"
means here? Which XML file? The structure description can expand what is meant
by "the XML files" and then each member initialized from it can have a
"(initialized from XML file)" or "(from XML file)" snippet.
> + */
> +struct event_group {
> + struct pmt_feature_group *pfg;
> + int guid;
Should this be u32?
> +};
> +
> +/* Link: https://github.com/intel/Intel-PMT xml/CWF/OOBMSM/RMID-ENERGY *.xml */
404
> +static struct event_group energy_0x26696143 = {
> + .guid = 0x26696143,
> +};
> +
> +/* Link: https://github.com/intel/Intel-PMT xml/CWF/OOBMSM/RMID-PERF *.xml */
404
> +static struct event_group perf_0x26557651 = {
> + .guid = 0x26557651,
> +};
> +
> +static struct event_group *known_event_groups[] = {
> + &energy_0x26696143,
> + &perf_0x26557651,
> +};
One has to study this series further to understand where this is going. At this point
the data structure seems to be unnecessarily complex requiring (what appears to be)
a lot of unnecessary pointer wrangling. Reader can ask here ... why pointers, why
not just an array of structs?. Adding information to explain
this choice will help to understand this work and make this easier to review.
> +
> +#define NUM_KNOWN_GROUPS ARRAY_SIZE(known_event_groups)
> +
> +static bool configure_events(struct event_group *e, struct pmt_feature_group *p)
configure_events() is an unexpected name for a function that returns true/false.
There is no explanation for this and reader needs to read following patches to
understand what its purpose is.
> +{
> + return false;
> +}
> +
> +DEFINE_FREE(intel_pmt_put_feature_group, struct pmt_feature_group *, \
> + if (!IS_ERR_OR_NULL(_T)) \
> + intel_pmt_put_feature_group(_T))
> +
Please document get_pmt_feature().
> +static bool get_pmt_feature(enum pmt_feature_id feature)
> +{
> + struct pmt_feature_group *p __free(intel_pmt_put_feature_group) = NULL;
> + struct event_group **peg;
> + bool ret;
> +
> + p = intel_pmt_get_regions_by_feature(feature);
> +
> + if (IS_ERR_OR_NULL(p))
> + return false;
> +
> + for (peg = &known_event_groups[0]; peg < &known_event_groups[NUM_KNOWN_GROUPS]; peg++) {
> + for (int i = 0; i < p->count; i++) {
> + if ((*peg)->guid == p->regions[i].guid) {
> + ret = configure_events((*peg), p);
Unnecessary parenthesis?
> + if (ret) {
This introduces too much confusion. It is custom for "0" to indicate success but this uses
boolean that is an unclear choice for a function that turns out (looking a few patches ahead)
to be complex. Please change "configure_events()" to have proper return codes. For example, it
allocates memory and when that fails it should return "-ENOMEM", not "false".
> + (*peg)->pfg = no_free_ptr(p);
> + return true;
> + }
> + break;
> + }
> + }
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Ask OOBMSM discovery driver for all the RMID based telemetry groups
> + * that it supports.
This comment implies that get_pmt_feature() is an OOBMSM call?
> + */
> +bool intel_aet_get_events(void)
> +{
> + bool ret1, ret2;
> +
> + ret1 = get_pmt_feature(FEATURE_PER_RMID_ENERGY_TELEM);
> + ret2 = get_pmt_feature(FEATURE_PER_RMID_PERF_TELEM);
> +
> + return ret1 || ret2;
> +}
> +
> +void __exit intel_aet_exit(void)
> +{
> + struct event_group **peg;
> +
> + for (peg = &known_event_groups[0]; peg < &known_event_groups[NUM_KNOWN_GROUPS]; peg++) {
> + if ((*peg)->pfg) {
> + intel_pmt_put_feature_group((*peg)->pfg);
> + (*peg)->pfg = NULL;
> + }
> + }
> +}
> diff --git a/arch/x86/kernel/cpu/resctrl/Makefile b/arch/x86/kernel/cpu/resctrl/Makefile
> index 28ae1c88b2ac..8b4603cad783 100644
> --- a/arch/x86/kernel/cpu/resctrl/Makefile
> +++ b/arch/x86/kernel/cpu/resctrl/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_X86_CPU_RESCTRL) += core.o rdtgroup.o monitor.o
> obj-$(CONFIG_X86_CPU_RESCTRL) += ctrlmondata.o
> +obj-$(CONFIG_INTEL_AET_RESCTRL) += intel_aet.o
> obj-$(CONFIG_INTEL_AET_RESCTRL) += fake_intel_aet_features.o
> obj-$(CONFIG_RESCTRL_FS_PSEUDO_LOCK) += pseudo_lock.o
>
Reinette
next prev parent reply other threads:[~2025-05-08 15:53 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 [this message]
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
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=85c670f4-e34d-46da-8458-b7233a902a5f@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