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 v12 24/31] x86/resctrl: Handle number of RMIDs supported by RDT_RESOURCE_PERF_PKG
Date: Thu, 23 Oct 2025 10:48:56 -0700 [thread overview]
Message-ID: <c25144f8-f6e5-407c-a6a8-f382beaabb50@intel.com> (raw)
In-Reply-To: <20251013223348.103390-25-tony.luck@intel.com>
Hi Tony,
On 10/13/25 3:33 PM, 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
> the event group's telemetry regions) as unusable. Note that the rdt_options[]
> structure must now be writable at run-time.
>
> Limit an event group's number of possible monitor resource groups
> to the lowest number of "hardware counters" if the user explicitly
> requests to enable an under-resourced event group.
How about:
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
> event_group::num_rmids so that min(r->num_rmid, e->num_rmids) won't
> complain about mixing signed and unsigned types. Print r->num_rmid as
> unsigned value in rdt_num_rmids_show().
"Print r->num_rmid ..." can be dropped since that is clear from the patch.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
...
> @@ -156,21 +168,59 @@ static bool skip_telem_region(struct telemetry_region *tr, struct event_group *e
> return false;
> }
>
> +/* Side effect: Detects unusable regions and marks them as unusable */
:/
> +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++) {
> + tr = &p->regions[i];
> + if (skip_telem_region(tr, e)) {
> + mark_telem_region_unusable(tr);
> + continue;
> + }
> +
> + if (tr->num_rmids < e->num_rmids)
> + ret = false;
> + }
> +
> + return ret;
> +}
This does not look right. Wouldn't this return "true" for all_regions_have_sufficient_rmid()
when there are no usable regions? Trying to have one function do two things is not working well here.
This also seems awkward where the regions are marked as unusable here as a "side effect" but then
later the caller attempts to track "usable_events" separately? This change does not look to be
integrated well.
Why not just determine which regions are usable as a first step and from then on just interact with
usable regions?
> +
> 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 usable_events = false;
>
This flow can start by determining and mark which regions are usable. Could be something like:
if (!group_has_usable_regions(e, p))
return false;
To reduce churn group_has_usable_regions() can be introduced in patch #17 to replace the open
code of it in enable_events().
From this point the "feature group" is guaranteed to have at least one telemetry region usable
by the associated "event group" and all interactions can be with just the usable regions within it.
For example, all_regions_have_sufficient_rmid() can change to:
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;
}
> + /* 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;
> +
> for (int i = 0; i < p->count; i++) {
> - if (skip_telem_region(&p->regions[i], e)) {
> - mark_telem_region_unusable(&p->regions[i]);
> + if (!p->regions[i].addr)
> continue;
> - }
> + /*
> + * e->num_rmids only adjusted lower if user (via rdt= kernel
> + * parameter) forces an event group with insufficient RMID
> + * to be enabled.
> + */
> + e->num_rmids = min(e->num_rmids, p->regions[i].num_rmids);
> usable_events = true;
> }
>
> if (!usable_events)
> return false;
>
> + if (r->mon.num_rmid)
> + r->mon.num_rmid = min(r->mon.num_rmid, e->num_rmids);
> + else
> + r->mon.num_rmid = e->num_rmids;
> +
> for (int j = 0; j < e->num_events; j++)
> resctrl_enable_mon_event(e->evts[j].id, true,
> e->evts[j].bin_bits, &e->evts[j]);
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index 2238a5536f4b..f18cc5b38315 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -1135,7 +1135,7 @@ static int rdt_num_rmids_show(struct kernfs_open_file *of,
> {
> struct rdt_resource *r = rdt_kn_parent_priv(of->kn);
>
> - seq_printf(seq, "%d\n", r->mon.num_rmid);
> + seq_printf(seq, "%u\n", r->mon.num_rmid);
>
> return 0;
> }
Reinette
next prev parent reply other threads:[~2025-10-23 17:49 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 22:33 [PATCH v12 00/31] x86,fs/resctrl telemetry monitoring Tony Luck
2025-10-13 22:33 ` [PATCH v12 01/31] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-10-23 4:07 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 02/31] x86/resctrl: Move L3 initialization into new helper function Tony Luck
2025-10-13 22:33 ` [PATCH v12 03/31] x86/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-10-23 4:08 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 04/31] x86/resctrl: Clean up domain_remove_cpu_ctrl() Tony Luck
2025-10-13 22:33 ` [PATCH v12 05/31] x86,fs/resctrl: Refactor domain create/remove using struct rdt_domain_hdr Tony Luck
2025-10-23 4:15 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 06/31] x86,fs/resctrl: Use struct rdt_domain_hdr when reading counters Tony Luck
2025-10-23 4:17 ` Reinette Chatre
2025-10-23 20:27 ` Luck, Tony
2025-10-13 22:33 ` [PATCH v12 07/31] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-10-23 4:18 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 08/31] x86,fs/resctrl: Rename some L3 specific functions Tony Luck
2025-10-23 4:21 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 09/31] fs/resctrl: Make event details accessible to functions when reading events Tony Luck
2025-10-13 22:33 ` [PATCH v12 10/31] x86,fs/resctrl: Handle events that can be read from any CPU Tony Luck
2025-10-23 4:22 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 11/31] x86,fs/resctrl: Support binary fixed point event counters Tony Luck
2025-10-13 22:33 ` [PATCH v12 12/31] x86,fs/resctrl: Add an architectural hook called for each mount Tony Luck
2025-10-13 22:33 ` [PATCH v12 13/31] x86,fs/resctrl: Add and initialize rdt_resource for package scope monitor Tony Luck
2025-10-23 4:33 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 14/31] x86/resctrl: Discover hardware telemetry events Tony Luck
2025-10-23 4:28 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 15/31] x86,fs/resctrl: Fill in details of events for guid 0x26696143 and 0x26557651 Tony Luck
2025-10-23 4:28 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 16/31] x86,fs/resctrl: Add architectural event pointer Tony Luck
2025-10-23 4:34 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 17/31] x86/resctrl: Find and enable usable telemetry events Tony Luck
2025-10-23 4:35 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 18/31] fs/resctrl: Split L3 dependent parts out of __mon_event_count() Tony Luck
2025-10-23 4:37 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 19/31] x86/resctrl: Read telemetry events Tony Luck
2025-10-23 4:47 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 20/31] fs/resctrl: Refactor mkdir_mondata_subdir() Tony Luck
2025-10-23 17:45 ` Reinette Chatre
2025-10-27 23:00 ` Luck, Tony
2025-10-28 16:00 ` Reinette Chatre
2025-10-28 17:14 ` Luck, Tony
2025-10-28 17:40 ` Reinette Chatre
2025-10-28 18:40 ` Luck, Tony
2025-10-28 23:55 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 21/31] fs/resctrl: Refactor rmdir_mondata_subdir_allrdtgrp() Tony Luck
2025-10-23 17:45 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 22/31] x86,fs/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-10-23 17:46 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 23/31] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2025-10-23 17:45 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 24/31] x86/resctrl: Handle number of RMIDs supported by RDT_RESOURCE_PERF_PKG Tony Luck
2025-10-23 17:48 ` Reinette Chatre [this message]
2025-10-13 22:33 ` [PATCH v12 25/31] fs/resctrl: Move allocation/free of closid_num_dirty_rmid[] Tony Luck
2025-10-23 17:49 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 26/31] x86,fs/resctrl: Compute number of RMIDs as minimum across resources Tony Luck
2025-10-13 22:33 ` [PATCH v12 27/31] fs/resctrl: Move RMID initialization to first mount Tony Luck
2025-10-23 17:49 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 28/31] x86/resctrl: Enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-10-23 17:50 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 29/31] fs/resctrl: Provide interface to create architecture specific debugfs area Tony Luck
2025-10-23 17:50 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 30/31] x86/resctrl: Add debugfs files to show telemetry aggregator status Tony Luck
2025-10-23 17:50 ` Reinette Chatre
2025-10-13 22:33 ` [PATCH v12 31/31] x86,fs/resctrl: Update documentation for telemetry events Tony Luck
2025-10-23 17:52 ` Reinette Chatre
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=c25144f8-f6e5-407c-a6a8-f382beaabb50@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;
as well as URLs for NNTP newsgroup(s).