Archive-only list for patches
 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>, Chen Yu <yu.c.chen@intel.com>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
	<patches@lists.linux.dev>
Subject: Re: [PATCH v13 25/32] x86/resctrl: Handle number of RMIDs supported by RDT_RESOURCE_PERF_PKG
Date: Thu, 13 Nov 2025 14:51:45 -0800	[thread overview]
Message-ID: <50149b02-d6ea-4fb2-806a-f16e80d3d52b@intel.com> (raw)
In-Reply-To: <20251029162118.40604-26-tony.luck@intel.com>

Hi Tony,

On 10/29/25 9:21 AM, Tony Luck wrote:
> There are now three meanings for "number of RMIDs":
> 
> 1) The number for legacy features enumerated by CPUID leaf 0xF. This
> is the maximum number of distinct values that can be loaded into
> MSR_IA32_PQR_ASSOC. Note that systems with Sub-NUMA Cluster mode enabled
> will force scaling down the CPUID enumerated value by the number of SNC
> nodes per L3-cache.
> 
> 2) The number of registers in MMIO space for each event. This
> is enumerated in the XML files and is the value initialized into
> event_group::num_rmids.
> 
> 3) The number of "hardware counters" (this isn't a strictly accurate
> description of how things work, but serves as a useful analogy that
> does describe the limitations) feeding to those MMIO registers. This
> is enumerated in telemetry_region::num_rmids returned from the call to
> intel_pmt_get_regions_by_feature()
> 
> Event groups with insufficient "hardware counters" to track all RMIDs
> are difficult for users to use, since the system may reassign "hardware
> counters" at any time. This means that users cannot reliably collect
> two consecutive event counts to compute the rate at which events are
> occurring.
> 
> Introduce rdt_set_feature_disabled() to mark any under-resourced event groups
> (those with telemetry_region::num_rmids < event_group::num_rmids  for any of

Extra space above, also note how line lengths differ between paragraphs.

> the event group's telemetry regions) as unusable.  Note that the rdt_options[]
> structure must now be writable at run-time.
> 
> Limit an under-resourced event group's number of possible monitor
> resource groups to the lowest number of "hardware counters" if the
> user explicitly requests to enable it.
> 
> Scan all enabled event groups and assign the RDT_RESOURCE_PERF_PKG
> resource "num_rmids" value to the smallest of these values as this value
> will be used later to compare against the number of RMIDs supported
> by other resources to determine how many monitoring resource groups
> are supported.
> 
> N.B. Change type of rdt_resource::num_rmid to u32 to match type of

resctrl_mon::num_rmid

> event_group::num_rmids so that min(r->num_rmid, e->num_rmids) won't
> complain about mixing signed and unsigned types.

May be worthwhile to highlight that resctrl_mon::num_rmid is already
used as a u32 so changing its type does not need to cascade into all
users. Something like "Change type of resctrl_mon::num_rmid to u32 to
match its usage and the type of ..."


> diff --git a/arch/x86/kernel/cpu/resctrl/intel_aet.c b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> index 781ca8ede39e..252a3fd4260c 100644
> --- a/arch/x86/kernel/cpu/resctrl/intel_aet.c
> +++ b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> @@ -25,6 +25,7 @@
>  #include <linux/intel_pmt_features.h>
>  #include <linux/intel_vsec.h>
>  #include <linux/io.h>
> +#include <linux/minmax.h>
>  #include <linux/overflow.h>
>  #include <linux/printk.h>
>  #include <linux/rculist.h>
> @@ -57,6 +58,7 @@ struct pmt_event {
>   * struct event_group - All information about a group of telemetry events.
>   * @feature:		Argument to intel_pmt_get_regions_by_feature() to
>   *			discover if this event_group is supported.
> + * @name:		Name for this group (used by boot rdt= option)
>   * @pfg:		Points to the aggregated telemetry space information
>   *			returned by the intel_pmt_get_regions_by_feature()
>   *			call to the INTEL_PMT_TELEMETRY driver that contains
> @@ -64,6 +66,10 @@ struct pmt_event {
>   *			Valid if the system supports the event group.
>   *			NULL otherwise.
>   * @guid:		Unique number per XML description file.
> + * @num_rmids:		Number of RMIDs supported by this group. May be
> + *			adjusted downwards if enumeration from
> + *			intel_pmt_get_regions_by_feature() indicates fewer
> + *			RMIDs can be tracked simultaneously.
>   * @mmio_size:		Number of bytes of MMIO registers for this group.
>   * @num_events:		Number of events in this group.
>   * @evts:		Array of event descriptors.
> @@ -71,10 +77,12 @@ struct pmt_event {
>  struct event_group {
>  	/* Data fields for additional structures to manage this group. */
>  	enum pmt_feature_id		feature;
> +	char				*name;
>  	struct pmt_feature_group	*pfg;
>  
>  	/* Remaining fields initialized from XML file. */
>  	u32				guid;
> +	u32				num_rmids;

This addition is to resctrl where there is already a resctrl_mon::num_rmid.
Can this naming be made consistent with resctrl instead of INTEL_PMT_TELEMETRY?

>  	size_t				mmio_size;
>  	unsigned int			num_events;
>  	struct pmt_event		evts[] __counted_by(num_events);
> @@ -89,7 +97,9 @@ struct event_group {
>   */
>  static struct event_group energy_0x26696143 = {
>  	.feature	= FEATURE_PER_RMID_ENERGY_TELEM,
> +	.name		= "energy",
>  	.guid		= 0x26696143,
> +	.num_rmids	= 576,
>  	.mmio_size	= XML_MMIO_SIZE(576, 2, 3),
>  	.num_events	= 2,
>  	.evts		= {
> @@ -104,7 +114,9 @@ static struct event_group energy_0x26696143 = {
>   */
>  static struct event_group perf_0x26557651 = {
>  	.feature	= FEATURE_PER_RMID_PERF_TELEM,
> +	.name		= "perf",
>  	.guid		= 0x26557651,
> +	.num_rmids	= 576,
>  	.mmio_size	= XML_MMIO_SIZE(576, 7, 3),
>  	.num_events	= 7,
>  	.evts		= {
> @@ -174,11 +186,54 @@ static bool group_has_usable_regions(struct event_group *e, struct pmt_feature_g
>  	return usable_regions;
>  }
>  
> +static bool all_regions_have_sufficient_rmid(struct event_group *e, struct pmt_feature_group
> +*p)
> +{
> +	struct telemetry_region *tr;
> +	bool ret = true;
> +
> +	for (int i = 0; i < p->count; i++) {
> +		if (!p->regions[i].addr)
> +			continue;
> +		tr = &p->regions[i];
> +		if (tr->num_rmids < e->num_rmids)
> +			ret = false;
> +	}
> +
> +	return ret;
> +}
> +
>  static bool enable_events(struct event_group *e, struct pmt_feature_group *p)
>  {
> +	struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_PERF_PKG].r_resctrl;
> +
>  	if (!group_has_usable_regions(e, p))
>  		return false;
>  
> +	/* Disable feature if insufficient RMIDs */
> +	if (!all_regions_have_sufficient_rmid(e, p))
> +		rdt_set_feature_disabled(e->name);
> +
> +	/* User can override above disable from kernel command line */
> +	if (!rdt_is_feature_enabled(e->name))
> +		return false;

Considering this from the user's perspective I do not think there is an easy way for user space
to know that the feature was force disabled and that there is an option to override this.
What is the use case considered here? If I understand correctly there may be a way to deduce this
by consulting files in /sys/class/intel_pmt/ where the telemetry regions' number of supported
RMID is printed. A user can compare that to the XML files to determine that there is an issue
that can explain resctrl not exposing the feature. Considering this difficulty I wonder if it
may be helpful to print an error message here? This is of course not perfect since the kernel
log cannot be guaranteed to forever contain it ... but it may help?

Reinette

  reply	other threads:[~2025-11-13 22:51 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 16:20 [PATCH v13 00/32] x86,fs/resctrl telemetry monitoring Tony Luck
2025-10-29 16:20 ` [PATCH v13 01/32] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-10-29 16:20 ` [PATCH v13 02/32] x86/resctrl: Move L3 initialization into new helper function Tony Luck
2025-10-29 16:20 ` [PATCH v13 03/32] x86/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-10-29 16:20 ` [PATCH v13 04/32] x86/resctrl: Clean up domain_remove_cpu_ctrl() Tony Luck
2025-10-29 16:20 ` [PATCH v13 05/32] x86,fs/resctrl: Refactor domain create/remove using struct rdt_domain_hdr Tony Luck
2025-11-12 19:18   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 06/32] fs/resctrl: Split L3 dependent parts out of __mon_event_count() Tony Luck
2025-10-29 16:20 ` [PATCH v13 07/32] x86,fs/resctrl: Use struct rdt_domain_hdr when reading counters Tony Luck
2025-11-12 19:19   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 08/32] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-11-13  4:01   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 09/32] x86,fs/resctrl: Rename some L3 specific functions Tony Luck
2025-11-13  4:01   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 10/32] fs/resctrl: Make event details accessible to functions when reading events Tony Luck
2025-10-29 16:20 ` [PATCH v13 11/32] x86,fs/resctrl: Handle events that can be read from any CPU Tony Luck
2025-10-30  6:14   ` Chen, Yu C
2025-10-30 15:54     ` Luck, Tony
2025-10-30 16:18       ` Chen, Yu C
2025-11-13  4:02   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 12/32] x86,fs/resctrl: Support binary fixed point event counters Tony Luck
2025-11-05 14:42   ` Dave Martin
2025-11-05 23:31     ` Luck, Tony
2025-11-06  0:09       ` Reinette Chatre
2025-11-11 17:22         ` Dave Martin
2025-11-12 16:12           ` Reinette Chatre
2025-11-06  2:27       ` Luck, Tony
2025-11-11 17:31         ` Dave Martin
2025-11-14 18:39           ` Luck, Tony
2025-11-11 17:16       ` Dave Martin
2025-11-14 18:51         ` Luck, Tony
2025-11-10 16:52     ` Luck, Tony
2025-11-11 17:34       ` Dave Martin
2025-11-12 13:08   ` David Laight
2025-10-29 16:20 ` [PATCH v13 13/32] x86,fs/resctrl: Add an architectural hook called for each mount Tony Luck
2025-10-29 16:20 ` [PATCH v13 14/32] x86,fs/resctrl: Add and initialize rdt_resource for package scope monitor Tony Luck
2025-11-13  4:04   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 15/32] fs/resctrl: Cleanup as L3 is no longer the only monitor resource Tony Luck
2025-11-13  4:05   ` Reinette Chatre
2025-10-29 16:20 ` [PATCH v13 16/32] x86/resctrl: Discover hardware telemetry events Tony Luck
2025-11-13  4:11   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 17/32] x86,fs/resctrl: Fill in details of events for guid 0x26696143 and 0x26557651 Tony Luck
2025-11-13 22:38   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 18/32] x86,fs/resctrl: Add architectural event pointer Tony Luck
2025-10-29 16:21 ` [PATCH v13 19/32] x86/resctrl: Find and enable usable telemetry events Tony Luck
2025-11-13 22:46   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 20/32] x86/resctrl: Read " Tony Luck
2025-11-13 22:47   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 21/32] fs/resctrl: Refactor mkdir_mondata_subdir() Tony Luck
2025-11-13 22:48   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 22/32] fs/resctrl: Refactor rmdir_mondata_subdir_allrdtgrp() Tony Luck
2025-11-13 22:48   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 23/32] x86,fs/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-10-29 16:21 ` [PATCH v13 24/32] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2025-10-29 16:21 ` [PATCH v13 25/32] x86/resctrl: Handle number of RMIDs supported by RDT_RESOURCE_PERF_PKG Tony Luck
2025-11-13 22:51   ` Reinette Chatre [this message]
2025-11-14 21:55     ` Luck, Tony
2025-11-14 23:26       ` Reinette Chatre
2025-11-17 16:37         ` Luck, Tony
2025-11-17 17:31           ` Reinette Chatre
2025-11-17 18:52             ` Luck, Tony
2025-11-18 16:48               ` Reinette Chatre
2025-11-18 17:35                 ` Luck, Tony
2025-11-18 18:11                   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 26/32] fs/resctrl: Move allocation/free of closid_num_dirty_rmid[] Tony Luck
2025-11-13 22:51   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 27/32] x86,fs/resctrl: Compute number of RMIDs as minimum across resources Tony Luck
2025-10-29 16:21 ` [PATCH v13 28/32] fs/resctrl: Move RMID initialization to first mount Tony Luck
2025-10-29 16:21 ` [PATCH v13 29/32] x86/resctrl: Enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-11-13 22:52   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 30/32] fs/resctrl: Provide interface to create architecture specific debugfs area Tony Luck
2025-10-29 16:21 ` [PATCH v13 31/32] x86/resctrl: Add debugfs files to show telemetry aggregator status Tony Luck
2025-11-13 22:53   ` Reinette Chatre
2025-10-29 16:21 ` [PATCH v13 32/32] x86,fs/resctrl: Update documentation for telemetry events Tony Luck
2025-11-13 22:56   ` Reinette Chatre
2025-10-29 18:59 ` [PATCH v13 00/32] x86,fs/resctrl telemetry monitoring Luck, Tony
2025-11-05 15:33   ` Moger, Babu
2025-11-05 15:41     ` Luck, Tony
2025-12-17  0:28     ` Luck, Tony
2025-12-17 16:44       ` Moger, Babu
2025-12-17 17:08         ` Luck, Tony
2025-11-16 17:35 ` Drew Fustini
2025-11-17 16:52   ` Luck, Tony
2025-11-18 23:03     ` Drew Fustini
2025-11-18 23:12       ` Luck, Tony

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=50149b02-d6ea-4fb2-806a-f16e80d3d52b@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.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