From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>, Fenghua Yu <fenghuay@nvidia.com>,
"Wieczor-Retman, Maciej" <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 C" <yu.c.chen@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@lists.linux.dev" <patches@lists.linux.dev>
Subject: Re: [PATCH v17 13/32] x86,fs/resctrl: Add an architectural hook called for each mount
Date: Wed, 7 Jan 2026 18:42:51 -0800 [thread overview]
Message-ID: <36239cc0-0a25-40a9-86d1-57236aa087df@intel.com> (raw)
In-Reply-To: <aV73RiFGJvYxAeo2@agluck-desk3>
Hi Tony,
On 1/7/26 4:16 PM, Luck, Tony wrote:
> On Wed, Jan 07, 2026 at 03:09:24PM -0800, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 1/7/26 2:27 PM, Luck, Tony wrote:
>>> On Wed, Jan 07, 2026 at 02:09:35PM -0800, Reinette Chatre wrote:
>>>> Hi Tony,
>>>>> If these DO_ONCE macros are ever used heavily in run-time code, it might
>>>>> be better for once_lock and once_mutex to be statically defined in each
>>>>> invocation of the DO_ONCE() and DO_ONCE_SLEEPABLE() macros. But the fact
>>>>> that the static key protects the spinlock/mutex from being called may
>>>>> mean that it is practically hard to hit problems.
>>>>
>>>> Which problems do you have in mind? One problem I see is that since these "once"
>>>> functions are globally forced to be serialized this may cause unnecessary delays,
>>>> for example during initialization. I do not think this impacts the resctrl intended
>>>> usage since resctrl_arch_pre_mount() is not called during initialization and is
>>>> already ok with delays (it is on a "slow" path).
>>>
>>> Reinette
>>>
>>> Yes. Unnecessary delays due to serialization. But that only happens if
>>> the first call to a DO_ONCE*() instance overlaps with another first
>>> call. It might be quite hard to hit that during boot unless there are
>>> many uses of DO_ONCE*()
>>>
>>> Looking at this some more, DO_ONCE() is overkill for mounting resctrl. The
>>> static key part is there so that DO_ONCE*() can be safely used in some
>>> hot code path without adding overhead of checking some "bool done" type
>>> variable and branching around it. I don't see anyone except validation
>>> executing resctrl mounts at multiple times per second.
>>>
>>> But it does make the code easier to read with a single line with obvious
>>> meaning instead of multiple lines with declarations, initializations,
>>> and if () conditions.
>>
>> I am ok with using DO_ONCE_SLEEPABLE(). The next question (perhaps nitpicking?) is
>> if it is resctrl fs or the arch's decision to use this. That is, whether the flow is
>> something like below where the arch decides:
>> arch/x86/kernel/cpu/resctrl/core.c:
>> void resctrl_arch_pre_mount(void)
>> {
>> DO_ONCE_SLEEPABLE(aet_specific_call);
>> }
>
> The AET code in resctrl_arch_pre_mount() includes building the domains.
> That needs the domain_list_lock mutex and domain_add_cpu_mon() which are
> both static in core.c. So either they need to be unstatic'd and added
> to "internal.h", or that part of the code needs to stay in core.c
>
> Opinion on making these available to intel_aet.c? I'm not a fan.
ok, that is fair.
>
> Keeping it in core.c means finding out if intel_aet_get_events()
> succeeded or not. DO_ONCE_SLEEPABLE() doesn't return the return value
> of the called function. It just returns true/false to say if it called
> the function.
>
> So with this approach I have:
>
> void resctrl_arch_pre_mount(void)
> {
> struct rdt_resource *r = &rdt_resources_all[RDT_RESOURCE_PERF_PKG].r_resctrl;
> int cpu;
>
> if (!DO_ONCE_SLEEPABLE(intel_aet_get_events))
> return;
>
Thank you for considering. This is getting difficult to read.
> // intel_aet_get_events() sets mon_capable if it succeeds
> if (!r->mon_capable)
> return;
>
> /*
> * Late discovery of telemetry events means the domains for the
> * resource were not built. Do that now.
> */
> cpus_read_lock();
> mutex_lock(&domain_list_lock);
> rdt_mon_capable = true;
> for_each_online_cpu(cpu)
> domain_add_cpu_mon(cpu, r);
> mutex_unlock(&domain_list_lock);
> cpus_read_unlock();
> }
>
> It does reduce by one the number of stubs. intel_aet_add_debugfs() can
> be static in intel_aet.c
>
>> fs/resctrl/rdtgroup.c:
>> static int rdt_get_tree(struct fs_context *fc)
>> {
>> ...
>> resctrl_arch_pre_mount();
>> ...
>> }
>>
>> or something like below where resctrl fs dictates the function can only be called once:
>>
>> arch/x86/kernel/cpu/resctrl/core.c:
>> void resctrl_arch_pre_mount(void)
>> {
>> /* AET specific code */
> This is the minimal change from my current series. So my laziness factor
> leans toward it.
>
>> }
>>
>> fs/resctrl/rdtgroup.c:
>> static int rdt_get_tree(struct fs_context *fc)
>> {
>> ...
>> DO_ONCE_SLEEPABLE(resctrl_arch_pre_mount);
>> ...
>> }
>>
>> It looks to me as though the first option creates opportunity for better isolation
>> of AET code into arch/x86/kernel/cpu/resctrl/intel_aet.c, specifically, it needs fewer AET
>> stubs in arch/x86/kernel/cpu/resctrl/internal.h. I do not envision resctrl fs needing
>> to call resctrl_arch_pre_mount() multiple times but the safe pattern appears to be to
>> place DO_ONCE* in a helper function to ensure that only one static key is ever created.
>>
>> While the first option allows more flexibility to the arch that should not be a reason though
>> since this is internal and we can always change to better accommodate arch requirements.
>> The question here is just what is best for AET support. What do you think?
>
> The current usage for resctrl_arch_pre_mount() is that it only needs to
> be called once. As you say, that could be changed if a new requirement
> appears. But the simpler approach today is to put the
> DO_ONCE_SLEEPABLE() into rdt_get_tree()
Thank you for considering the options. Placing DO_ONCE_SLEEPABLE() in
rdt_get_tree() is fine by me.
Reinette
next prev parent reply other threads:[~2026-01-08 2:42 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 17:20 [PATCH v17 00/32] x86,fs/resctrl telemetry monitoring Tony Luck
2025-12-17 17:20 ` [PATCH v17 01/32] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-12-17 17:20 ` [PATCH v17 02/32] x86/resctrl: Move L3 initialization into new helper function Tony Luck
2025-12-17 17:20 ` [PATCH v17 03/32] x86/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-12-17 17:20 ` [PATCH v17 04/32] x86/resctrl: Clean up domain_remove_cpu_ctrl() Tony Luck
2025-12-17 17:20 ` [PATCH v17 05/32] x86,fs/resctrl: Refactor domain create/remove using struct rdt_domain_hdr Tony Luck
2025-12-17 17:20 ` [PATCH v17 06/32] fs/resctrl: Split L3 dependent parts out of __mon_event_count() Tony Luck
2025-12-17 17:20 ` [PATCH v17 07/32] x86,fs/resctrl: Use struct rdt_domain_hdr when reading counters Tony Luck
2025-12-17 17:20 ` [PATCH v17 08/32] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-12-17 17:20 ` [PATCH v17 09/32] x86,fs/resctrl: Rename some L3 specific functions Tony Luck
2025-12-17 17:20 ` [PATCH v17 10/32] fs/resctrl: Make event details accessible to functions when reading events Tony Luck
2025-12-17 17:20 ` [PATCH v17 11/32] x86,fs/resctrl: Handle events that can be read from any CPU Tony Luck
2025-12-17 17:20 ` [PATCH v17 12/32] x86,fs/resctrl: Support binary fixed point event counters Tony Luck
2025-12-17 17:21 ` [PATCH v17 13/32] x86,fs/resctrl: Add an architectural hook called for each mount Tony Luck
2026-01-05 19:17 ` Borislav Petkov
2026-01-05 19:39 ` Luck, Tony
2026-01-05 20:04 ` Borislav Petkov
2026-01-05 20:15 ` Luck, Tony
2026-01-07 17:29 ` Reinette Chatre
2026-01-07 18:05 ` Luck, Tony
2026-01-07 19:33 ` Reinette Chatre
2026-01-07 20:25 ` Luck, Tony
2026-01-07 22:09 ` Reinette Chatre
2026-01-07 22:27 ` Luck, Tony
2026-01-07 23:09 ` Reinette Chatre
2026-01-08 0:16 ` Luck, Tony
2026-01-08 2:42 ` Reinette Chatre [this message]
2025-12-17 17:21 ` [PATCH v17 14/32] x86,fs/resctrl: Add and initialize a resource for package scope monitoring Tony Luck
2025-12-17 17:21 ` [PATCH v17 15/32] fs/resctrl: Emphasize that L3 monitoring resource is required for summing domains Tony Luck
2025-12-17 17:21 ` [PATCH v17 16/32] x86/resctrl: Discover hardware telemetry events Tony Luck
2025-12-17 17:21 ` [PATCH v17 17/32] x86,fs/resctrl: Fill in details of events for guid 0x26696143 and 0x26557651 Tony Luck
2025-12-17 17:21 ` [PATCH v17 18/32] x86,fs/resctrl: Add architectural event pointer Tony Luck
2025-12-17 17:21 ` [PATCH v17 19/32] x86/resctrl: Find and enable usable telemetry events Tony Luck
2026-01-09 12:16 ` Borislav Petkov
2026-01-09 16:17 ` Reinette Chatre
2026-01-09 16:53 ` Luck, Tony
2026-01-09 22:01 ` Borislav Petkov
2025-12-17 17:21 ` [PATCH v17 20/32] x86/resctrl: Read " Tony Luck
2025-12-17 17:21 ` [PATCH v17 21/32] fs/resctrl: Refactor mkdir_mondata_subdir() Tony Luck
2025-12-17 17:21 ` [PATCH v17 22/32] fs/resctrl: Refactor rmdir_mondata_subdir_allrdtgrp() Tony Luck
2025-12-17 17:21 ` [PATCH v17 23/32] x86,fs/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-12-17 17:21 ` [PATCH v17 24/32] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2026-01-09 22:16 ` Borislav Petkov
2026-01-09 22:20 ` Luck, Tony
2025-12-17 17:21 ` [PATCH v17 25/32] x86/resctrl: Handle number of RMIDs supported by RDT_RESOURCE_PERF_PKG Tony Luck
2025-12-17 17:21 ` [PATCH v17 26/32] fs/resctrl: Move allocation/free of closid_num_dirty_rmid[] Tony Luck
2025-12-17 17:21 ` [PATCH v17 27/32] x86,fs/resctrl: Compute number of RMIDs as minimum across resources Tony Luck
2025-12-17 17:21 ` [PATCH v17 28/32] fs/resctrl: Move RMID initialization to first mount Tony Luck
2025-12-17 17:21 ` [PATCH v17 29/32] x86/resctrl: Enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-12-17 17:21 ` [PATCH v17 30/32] fs/resctrl: Provide interface to create architecture specific debugfs area Tony Luck
2026-01-10 10:57 ` Borislav Petkov
2026-01-10 19:13 ` Luck, Tony
2026-01-10 19:42 ` Borislav Petkov
2026-01-10 23:29 ` Luck, Tony
2025-12-17 17:21 ` [PATCH v17 31/32] x86/resctrl: Add debugfs files to show telemetry aggregator status Tony Luck
2025-12-17 17:21 ` [PATCH v17 32/32] x86,fs/resctrl: Update documentation for telemetry events Tony Luck
2025-12-17 22:16 ` [PATCH v17 00/32] x86,fs/resctrl telemetry monitoring Reinette Chatre
2026-01-04 6:14 ` Borislav Petkov
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=36239cc0-0a25-40a9-86d1-57236aa087df@intel.com \
--to=reinette.chatre@intel.com \
--cc=Dave.Martin@arm.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--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