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>,
David E Box <david.e.box@intel.com>, <x86@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
<linux-kernel@vger.kernel.org>, <patches@lists.linux.dev>
Subject: Re: [PATCH v7 08/14] fs,x86,mpam/resctrl: Handle change in number of RMIDs on each mount
Date: Mon, 8 Jun 2026 16:21:10 -0700 [thread overview]
Message-ID: <2cd8dcac-9257-413e-b345-7c78bd77043f@intel.com> (raw)
In-Reply-To: <20260601195632.15876-9-tony.luck@intel.com>
Hi Tony,
On 6/1/26 12:56 PM, Tony Luck wrote:
> Application Energy Telemetry (AET) event enumeration takes place
> asynchronously. Linux builds the pmt_telemetry module into the kernel to
> kick of enumeration early enough that it completes before first mount of
> the resctrl file system.
>
> Allowing pmt_telemetry to be a loadable module means that it is possible
> for different numbers of RMIDs to be supported on each mount, depending
> on whether pmt_telemetry module is loaded.
>
> Add resctrl_arch_system_max_rmid_idx() interface to provide the maximum
> supported number of RMIDs on a system. For x86 this is RDT_RESOURCE_L3
> rdt_resource::mon.num_rmid (if L3 monitoring is enabled).
>
> Allocate the rmid_ptrs, rdt_l3_mon_domain::rmid_busy_llc, and
> rdt_l3_mon_domain::mbm_states based on the maximum possible.
This is a significant change to data structures expected to be
indexed by RMID. Could you please update kernel-doc of these members to reflect
the new usage?
>
> Initialize rmid_free_lru based on the number of RMIDs available for
> this mount.
>
Above three paragraps writes verbatim what can be seen in the patch self.
Could you please expand the changelog to help reader understand why these
changes are made?
This patch is quite difficult to decipher when one only has the code to consider.
> Note that some RMIDs may still be marked busy from a previous mount.
> Don't add these to the free list. Check current RMID limit in
> limbo_release_entry() and do not add out of range RMIDs to the
> free list.
>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
...
> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> index 1af8f965fdd0..934492c7e643 100644
> --- a/arch/x86/kernel/cpu/resctrl/core.c
> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> @@ -129,6 +129,18 @@ u32 resctrl_arch_system_num_rmid_idx(void)
> return num_rmids == U32_MAX ? 0 : num_rmids;
> }
>
> +/**
> + * resctrl_arch_system_max_rmid_idx - Largest possible number of RMIDs
> + *
> + * Return: If L3 monitoring is supported, largest possible comes from L3.
> + */
> +u32 resctrl_arch_system_max_rmid_idx(void)
> +{
> + struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_L3].r_resctrl;
> +
> + return r->mon_capable ? r->mon.num_rmid : resctrl_arch_system_num_rmid_idx();
> +}
> +
> struct rdt_resource *resctrl_arch_get_resource(enum resctrl_res_level l)
> {
> if (l >= RDT_NUM_RESOURCES)
> diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
> index 226ff6f532fa..7079870ca894 100644
> --- a/drivers/resctrl/mpam_resctrl.c
> +++ b/drivers/resctrl/mpam_resctrl.c
> @@ -272,6 +272,11 @@ u32 resctrl_arch_system_num_rmid_idx(void)
> return (mpam_pmg_max + 1) * (mpam_partid_max + 1);
> }
>
> +u32 resctrl_arch_system_max_rmid_idx(void)
> +{
> + return resctrl_arch_system_num_rmid_idx();
> +}
> +
> u32 resctrl_arch_rmid_idx_encode(u32 closid, u32 rmid)
> {
> return closid * (mpam_pmg_max + 1) + rmid;
> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
> index 327e7a863614..b374e2f84a75 100644
> --- a/fs/resctrl/monitor.c
> +++ b/fs/resctrl/monitor.c
> @@ -115,10 +115,17 @@ static inline struct rmid_entry *__rmid_entry(u32 idx)
>
> static void limbo_release_entry(struct rmid_entry *entry)
> {
> + u32 idx_limit = resctrl_arch_system_num_rmid_idx();
Having the code switch idx_limit to sometimes be resctrl_arch_system_num_rmid_idx()
and other times resctrl_arch_system_max_rmid_idx() makes this change difficult to
follow. I think it will help to use different variable names to differentiate
the context in which it is being used and not leave reader trying to understand
why there are *two* limits.
> lockdep_assert_held(&rdtgroup_mutex);
>
> rmid_limbo_count--;
> - list_add_tail(&entry->list, &rmid_free_lru);
> +
> + /*
> + * Limbo may be freeing an RMID from a previous mount where there
> + * were more RMIDs available.
> + */
> + if (resctrl_arch_rmid_idx_encode(entry->closid, entry->rmid) < idx_limit)
> + list_add_tail(&entry->list, &rmid_free_lru);
>
> if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID))
> closid_num_dirty_rmid[entry->closid]--;
> @@ -133,7 +140,7 @@ static void limbo_release_entry(struct rmid_entry *entry)
> void __check_limbo(struct rdt_l3_mon_domain *d, bool force_free)
> {
> struct rdt_resource *r = resctrl_arch_get_resource(RDT_RESOURCE_L3);
> - u32 idx_limit = resctrl_arch_system_num_rmid_idx();
> + u32 idx_limit = resctrl_arch_system_max_rmid_idx();
> struct rmid_entry *entry;
> u32 idx, cur_idx = 1;
> void *arch_mon_ctx;
> @@ -192,7 +199,7 @@ void __check_limbo(struct rdt_l3_mon_domain *d, bool force_free)
>
> bool has_busy_rmid(struct rdt_l3_mon_domain *d)
> {
> - u32 idx_limit = resctrl_arch_system_num_rmid_idx();
> + u32 idx_limit = resctrl_arch_system_max_rmid_idx();
>
> return find_first_bit(d->rmid_busy_llc, idx_limit) != idx_limit;
> }
> @@ -916,24 +923,32 @@ int setup_rmid_lru_list(void)
> return 0;
>
> /*
> - * Called on every mount, but the number of RMIDs cannot change
> - * after the first mount, so keep using the same set of rmid_ptrs[]
> - * until resctrl_exit(). Note that the limbo handler continues to
> - * access rmid_ptrs[] after resctrl is unmounted.
> + * Allocate the largest number of RMIDs that this system will ever
> + * need. These cannot be freed until resctrl_exit() because the limbo
> + * handler continues to access rmid_ptrs[] after resctrl is unmounted.
> */
> - if (rmid_ptrs)
> - return 0;
> + if (!rmid_ptrs) {
> + idx_limit = resctrl_arch_system_max_rmid_idx();
> + rmid_ptrs = kzalloc_objs(struct rmid_entry, idx_limit);
> + if (!rmid_ptrs)
> + return -ENOMEM;
> +
> + for (i = 0; i < idx_limit; i++) {
> + entry = &rmid_ptrs[i];
> + INIT_LIST_HEAD(&entry->list);
> +
> + resctrl_arch_rmid_idx_decode(i, &entry->closid, &entry->rmid);
> + }
> + }
>
> + /* Find how many RMIDs are needed for this mount */
> idx_limit = resctrl_arch_system_num_rmid_idx();
> - rmid_ptrs = kzalloc_objs(struct rmid_entry, idx_limit);
> - if (!rmid_ptrs)
> - return -ENOMEM;
>
> + INIT_LIST_HEAD(&rmid_free_lru);
> for (i = 0; i < idx_limit; i++) {
> entry = &rmid_ptrs[i];
> - INIT_LIST_HEAD(&entry->list);
> -
> - resctrl_arch_rmid_idx_decode(i, &entry->closid, &entry->rmid);
> + if (i && entry->busy)
> + continue;
> list_add_tail(&entry->list, &rmid_free_lru);
> }
>
> @@ -1156,7 +1171,7 @@ static void mbm_cntr_free_all(struct rdt_resource *r, struct rdt_l3_mon_domain *
> */
> static void resctrl_reset_rmid_all(struct rdt_resource *r, struct rdt_l3_mon_domain *d)
> {
> - u32 idx_limit = resctrl_arch_system_num_rmid_idx();
> + u32 idx_limit = resctrl_arch_system_max_rmid_idx();
> enum resctrl_event_id evt;
> int idx;
>
> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> index d2a1f88d8782..6d647b71c5db 100644
> --- a/fs/resctrl/rdtgroup.c
> +++ b/fs/resctrl/rdtgroup.c
> @@ -4416,7 +4416,7 @@ void resctrl_offline_mon_domain(struct rdt_resource *r, struct rdt_domain_hdr *h
> */
> static int domain_setup_l3_mon_state(struct rdt_resource *r, struct rdt_l3_mon_domain *d)
> {
> - u32 idx_limit = resctrl_arch_system_num_rmid_idx();
> + u32 idx_limit = resctrl_arch_system_max_rmid_idx();
> size_t tsize = sizeof(*d->mbm_states[0]);
> enum resctrl_event_id eventid;
> int idx;
Reinette
next prev parent reply other threads:[~2026-06-08 23:21 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 19:56 [PATCH v7 00/14] Allow AET to use PMT as loadable module Tony Luck
2026-06-01 19:56 ` [PATCH v7 01/14] fs/resctrl: Move functions to avoid forward references in subsequent fixes Tony Luck
2026-06-01 19:56 ` [PATCH v7 02/14] fs/resctrl: Free mon_data structures on rdt_get_tree() failure Tony Luck
2026-06-01 19:56 ` [PATCH v7 03/14] fs/resctrl: Fix use-after-free during unmount Tony Luck
2026-06-01 19:56 ` [PATCH v7 04/14] fs/resctrl: Fix deadlock for errors during mount Tony Luck
2026-06-01 19:56 ` [PATCH v7 05/14] x86/resctrl: Stop setting event_group::force_off on RMID shortage Tony Luck
2026-06-08 23:16 ` Reinette Chatre
2026-06-09 16:51 ` Luck, Tony
2026-06-09 23:02 ` Reinette Chatre
2026-06-10 20:01 ` Luck, Tony
2026-06-01 19:56 ` [PATCH v7 06/14] fs/resctrl: Add interface to disable a monitor event Tony Luck
2026-06-08 23:18 ` Reinette Chatre
2026-06-09 17:21 ` Luck, Tony
2026-06-09 23:02 ` Reinette Chatre
2026-06-10 20:56 ` Luck, Tony
2026-06-10 22:26 ` Reinette Chatre
2026-06-10 23:19 ` Luck, Tony
2026-06-11 21:22 ` Reinette Chatre
2026-06-01 19:56 ` [PATCH v7 07/14] x86/resctrl: Maintain a count of enabled monitor features Tony Luck
2026-06-08 23:18 ` Reinette Chatre
2026-06-09 18:46 ` Luck, Tony
2026-06-09 23:03 ` Reinette Chatre
2026-06-11 17:27 ` Luck, Tony
2026-06-01 19:56 ` [PATCH v7 08/14] fs,x86,mpam/resctrl: Handle change in number of RMIDs on each mount Tony Luck
2026-06-08 23:21 ` Reinette Chatre [this message]
2026-06-09 21:58 ` Luck, Tony
2026-06-09 23:35 ` Reinette Chatre
2026-06-11 17:40 ` Luck, Tony
2026-06-01 19:56 ` [PATCH v7 09/14] x86/resctrl: Add PMT registration API for AET enumeration callbacks Tony Luck
2026-06-08 23:21 ` Reinette Chatre
2026-06-01 19:56 ` [PATCH v7 10/14] platform/x86/intel/pmt: Register enumeration functions with resctrl Tony Luck
2026-06-08 23:22 ` Reinette Chatre
2026-06-09 22:11 ` Luck, Tony
2026-06-18 21:15 ` Luck, Tony
2026-06-22 15:46 ` Reinette Chatre
2026-06-22 23:00 ` Luck, Tony
2026-06-23 15:45 ` Reinette Chatre
2026-06-23 18:24 ` Luck, Tony
2026-06-01 19:56 ` [PATCH v7 11/14] mpam,x86/resctrl: Resolve INTEL_PMT_TELEMETRY symbols at runtime Tony Luck
2026-06-08 23:25 ` Reinette Chatre
2026-06-10 0:08 ` Luck, Tony
2026-06-10 15:27 ` Reinette Chatre
2026-06-10 15:49 ` Luck, Tony
2026-06-10 16:21 ` Reinette Chatre
2026-06-10 16:34 ` Luck, Tony
2026-06-10 16:46 ` Reinette Chatre
2026-06-10 17:24 ` Luck, Tony
2026-06-10 17:58 ` Reinette Chatre
2026-06-10 22:09 ` Luck, Tony
2026-06-11 18:01 ` Luck, Tony
2026-06-11 21:22 ` Reinette Chatre
2026-06-11 22:27 ` Luck, Tony
2026-06-12 18:04 ` Luck, Tony
2026-06-01 19:56 ` [PATCH v7 12/14] fs/resctrl: Call architecture hooks for every mount/unmount Tony Luck
2026-06-08 23:26 ` Reinette Chatre
2026-06-10 16:16 ` Luck, Tony
2026-06-01 19:56 ` [PATCH v7 13/14] x86/resctrl: Simplify Kconfig options for resctrl Tony Luck
2026-06-01 19:56 ` [PATCH v7 14/14] Documentation/filesystems/resctrl: Add footnote for telemetry fstab mount caveat Tony Luck
2026-06-08 23:26 ` Reinette Chatre
2026-06-10 16:19 ` 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=2cd8dcac-9257-413e-b345-7c78bd77043f@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=david.e.box@intel.com \
--cc=dfustini@baylibre.com \
--cc=fenghuay@nvidia.com \
--cc=hch@infradead.org \
--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
Powered by JetHome