All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: 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>,
	<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: Tue, 18 Nov 2025 09:35:31 -0800	[thread overview]
Message-ID: <aRyuY_TF5d6Me7MD@agluck-desk3> (raw)
In-Reply-To: <f3ec7e8b-b042-4d38-823f-4f4174cb9d09@intel.com>

On Tue, Nov 18, 2025 at 08:48:18AM -0800, Reinette Chatre wrote:
> Hi Tony,
> 
> On 11/17/25 10:52 AM, Luck, Tony wrote:
> > On Mon, Nov 17, 2025 at 09:31:41AM -0800, Reinette Chatre wrote:
> >> On 11/17/25 8:37 AM, Luck, Tony wrote:
> >>> On Fri, Nov 14, 2025 at 03:26:42PM -0800, Reinette Chatre wrote:
> >>>> On 11/14/25 1:55 PM, Luck, Tony wrote:
> >>>> How a system with two guid of the same feature type would work is not clear to me though. Looks
> >>>> like they cannot share events at all since an event is uniquely associated with a struct pmt_event
> >>>> that can belong to only one event group. If they may share events then enable_events()->resctrl_enable_mon_event()
> >>>> will complain loudly but still proceed and allow the event group to be enabled.
> >>>
> >>> I can't see a good reason why the same event would be enabled under
> >>> different guids present on the same system. We can revisit my assumption
> >>> if the "Duplicate enable for event" message shows up.
> >>
> >> This would be difficult to handle at that time, no? From what I can tell this would enable
> >> an unusable event group to actually be enabled resulting in untested and invalid flows.
> >> I think it will be safer to not enable an event group in this scenario and seems to math your
> >> expectation that this would be unexpected. The "Duplicate enable for event" message will still
> >> appear and we can still revisit those assumptions when they do, but the systems encountering
> >> them will not be running with enabled event groups that are not actually fully enabled.
> > 
> > There's a hardware cost to including an event in an aggregator.
> > Inclusing the same event in mutliple aggregators described by
> > different guids is really something that should never happen.
> > Just printing a warning and skipping the event seems an adequate
> > defense.
> 
> My concern is that after skipping the event there is a deceiving message that the event group was
> enabled successfully.

I can change resctrl_enable_mon_event() to return a "bool" to say
whether each event was successfully enabled.

Then change to:

	int skipped_events = 0;

	for (int j = 0; j < e->num_events; j++) {
		if (!resctrl_enable_mon_event(e->evts[j].id, true,
					      e->evts[j].bin_bits, &e->evts[j]))
			skipped_events++;
	}

	if (e->num_events == skipped_events) {
		pr_info("No events enabled in %s %s:0x%x\n", r->name, e->name, e->guid);
		return false;
	}

	if (skipped_events)
		pr_info("%s %s:0x%x monitoring detected (skipped %d events)\n", r->name,
			r->name, e->name, e->guid, skipped_events);
	else
		pr_info("%s %s:0x%x monitoring detected\n", r->name, e->name, e->guid);
> 
> ...
> 
> > ---
> > 
> > diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
> > index 08eb78acb988..25df1abc1537 100644
> > --- a/arch/x86/kernel/cpu/resctrl/internal.h
> > +++ b/arch/x86/kernel/cpu/resctrl/internal.h
> > @@ -241,6 +241,7 @@ int intel_aet_read_event(int domid, u32 rmid, void *arch_priv, u64 *val);
> >  void intel_aet_mon_domain_setup(int cpu, int id, struct rdt_resource *r,
> >  				struct list_head *add_pos);
> >  void intel_aet_add_debugfs(void);
> > +void intel_aet_option(bool force_off, const char *option, const char *suboption);
> >  #else
> >  static inline bool intel_aet_get_events(void) { return false; }
> >  static inline void __exit intel_aet_exit(void) { }
> > @@ -252,6 +253,7 @@ static inline int intel_aet_read_event(int domid, u32 rmid, void *arch_priv, u64
> >  static inline void intel_aet_mon_domain_setup(int cpu, int id, struct rdt_resource *r,
> >  					      struct list_head *add_pos) { }
> >  static inline void intel_aet_add_debugfs(void) { }
> > +static inline void intel_aet_option(bool force_off, const char *option, const char *suboption) { };
> 
> (nit: stray 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 5cae4119686e..68195f458c0b 100644
> > --- a/arch/x86/kernel/cpu/resctrl/core.c
> > +++ b/arch/x86/kernel/cpu/resctrl/core.c
> > @@ -842,6 +842,7 @@ static struct rdt_options rdt_options[] = {
> >  static int __init set_rdt_options(char *str)
> >  {
> >  	struct rdt_options *o;
> > +	char *suboption;
> >  	bool force_off;
> >  	char *tok;
> >  
> > @@ -851,6 +852,11 @@ static int __init set_rdt_options(char *str)
> >  		force_off = *tok == '!';
> >  		if (force_off)
> >  			tok++;
> > +		suboption = strpbrk(tok, ":");
> > +		if (suboption) {
> > +			*suboption++ = '\0';
> 
> This looks like an open code of strsep()?
> 
> > +			intel_aet_option(force_off, tok, suboption);
> > +		}
> 
> I think this can be simplified. It also looks possible to follow some patterns of existing
> option handling. 
> 
> By adding the force_on/force_off members to struct event_group I do not see the perf and
> energy options needed in rdt_options[] anymore. rdt_set_feature_disabled() and
> rdt_is_feature_enabled() now also seems unnecessary because the event_group::force_on and
> event_group::force_off are sufficient.
> 
> It looks to me that the entire token can be passed here to intel_aet_option() and it
> returns 1 to indicate that it was able to "handle" the token, 0 otherwise. If intel_aet_option()
> was able to handle the option then it is not necessary to do further parsing.
> "handle" means that it could successfully initialize the new members of struct event_group.
> 
> So instead, how about something like:
> 		if (intel_aet_option(force_off, tok))
> 			continue;
> 
> >  		for (o = rdt_options; o < &rdt_options[NUM_RDT_OPTIONS]; o++) {
> >  			if (strcmp(tok, o->name) == 0) {
> >  				if (force_off)
> > diff --git a/arch/x86/kernel/cpu/resctrl/intel_aet.c b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> > index 6028bfec229b..b3c61bcd3e8f 100644
> > --- a/arch/x86/kernel/cpu/resctrl/intel_aet.c
> > +++ b/arch/x86/kernel/cpu/resctrl/intel_aet.c
> > @@ -69,6 +69,9 @@ struct pmt_event {
> >   *			data for all telemetry regions type @feature.
> >   *			Valid if the system supports the event group.
> >   *			NULL otherwise.
> > + * @force_off:		Set true when "rdt" command line disables this @guid.
> 
> To be consistent, can also be true if event group was found to have insufficient RMID.
> 
> > + * @force_on:		Set true when "rdt" command line overrides disable of
> > + *			this @guid due to insufficeint @num_rmid.
> 
> "Set" can be dropped to be explicit of state instead of potentially confusing "Set" to
> be a verb.
> 
> insufficeint -> insufficient
> 
> >   * @guid:		Unique number per XML description file.
> >   * @num_rmid:		Number of RMIDs supported by this group. May be
> >   *			adjusted downwards if enumeration from
> > @@ -83,6 +86,7 @@ struct event_group {
> >  	enum pmt_feature_id		feature;
> >  	char				*name;
> >  	struct pmt_feature_group	*pfg;
> > +	bool				force_off, force_on;
> >  
> >  	/* Remaining fields initialized from XML file. */
> >  	u32				guid;
> > @@ -144,6 +148,26 @@ static struct event_group *known_event_groups[] = {
> >  	     _peg < &known_event_groups[ARRAY_SIZE(known_event_groups)];	\
> >  	     _peg++)
> >  
> > +void intel_aet_option(bool force_off, const char *option, const char *suboption)
> > +{
> > +	struct event_group **peg;
> > +	u32 guid;
> > +
> 
> Can use strsep() here to split provided token into name and guid. Take care to
> check if guid NULL before attempting kstrtou32().
> 
> > +	if (kstrtou32(suboption, 16, &guid))
> > +		return;
> > +
> > +	for_each_event_group(peg) {
> > +		if (!strcmp(option, (*peg)->name))
> 
> !strcmp() -> strcmp()?
> 
> > +			continue;
> > +		if ((*peg)->guid != guid)
> > +			continue;
> 
> If no guid provided then all event groups with matching name can have
> force_on/force_off member set to support user providing, for example: "!perf" to
> disable all perf event groups.
> 
> > +		if (force_off)
> > +			(*peg)->force_off = true;
> > +		else
> > +			(*peg)->force_on = true;
> > +	}
> > +}
> > +
> >  /*
> >   * Clear the address field of regions that did not pass the checks in
> >   * skip_telem_region() so they will not be used by intel_aet_read_event().
> > @@ -252,6 +276,9 @@ 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;
> >  	bool warn_disable = false;
> >  
> > +	if (e->force_off)
> > +		return false;
> > +
> >  	if (!group_has_usable_regions(e, p))
> >  		return false;
> >  
> 
> rdt_set_feature_disabled() that is around here can be replaced with setting
> event_group::force_off
> 
> > @@ -262,7 +289,7 @@ static bool enable_events(struct event_group *e, struct pmt_feature_group *p)
> >  	}
> >  
> >  	/* User can override above disable from kernel command line */
> > -	if (!rdt_is_feature_enabled(e->name)) {
> > +	if (!rdt_is_feature_enabled(e->name) && !e->force_on) {
> 
> rdt_is_feature_enabled() can be replaced with check of event_group::force_off
> 
> >  		if (warn_disable)
> >  			pr_info("Feature %s guid=0x%x not enabled due to insufficient RMIDs\n",
> >  				e->name, e->guid);
> > 
> > 
> 
> I believe changes I mention would simplify the implementation a lot while making it
> more powerful to support the, for example, "!perf" use case. What do you think?

Agreed. Simpler and more flexible. I'll make these changes.
> 
> Reinette

-Tony

  reply	other threads:[~2025-11-18 17:35 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
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 [this message]
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=aRyuY_TF5d6Me7MD@agluck-desk3 \
    --to=tony.luck@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=reinette.chatre@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.