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>,
Anil Keshavamurthy <anil.s.keshavamurthy@intel.com>,
Chen Yu <yu.c.chen@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
patches@lists.linux.dev
Subject: Re: [PATCH v5 27/29] fs/resctrl: Add file system mechanism for architecture info file
Date: Mon, 9 Jun 2025 11:49:42 -0700 [thread overview]
Message-ID: <aEcsxjWroliWf3G0@agluck-desk3> (raw)
In-Reply-To: <d2be3a4e-1075-459d-9bf7-b6aefcb93820@intel.com>
On Fri, Jun 06, 2025 at 02:14:56PM -0700, Reinette Chatre wrote:
> Hi Tony,
>
> On 6/6/25 10:30 AM, Luck, Tony wrote:
> > On Fri, Jun 06, 2025 at 09:26:06AM -0700, Reinette Chatre wrote:
> >> With /sys/kernel/debug/resctrl potentially mirroring /sys/fs/resctrl to
> >> support various debugging scenarios there may later be resource level
> >> debugging for which a "/sys/kernel/debug/resctrl/info/<resource>/<debugfile>" can
> >> be used. Considering this it looks to me as though one possible boundary could
> >> be to isolate arch specific debug to, for example, a new directory named
> >> "/sys/kernel/debug/resctrl/info/arch_debug_name_tbd/". By placing the
> >> arch debug in a sub-directory named "info" it avoids collision with resource
> >> group names with naming that also avoids collision with resource names since
> >> all these names are controlled by resctrl fs.
> >
> >
> > That seems like a good path. PoC patch below. Note that I put the dentry
> > for the debug info directory into struct rdt_resource. So no call from
> > architecture to file system code needed to access.
>
> ok, reading between the lines there is now a switch to per-resource
> requirement, which fits with the use.
>
> >
> > Directory layout looks like this:
> >
> > # tree /sys/kernel/debug/resctrl/
> > /sys/kernel/debug/resctrl/
> > └── info
> > ├── L2
> > ├── L3
> > ├── MB
> > └── SMBA
> >
>
> This looks like something that needs to be owned and managed by
> resctrl fs (more below).
>
> > 6 directories, 0 files
> >
> > -Tony
> >
> > ---
> >
> > diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
> > index 5e28e81b35f6..78dd0f8f7ad8 100644
> > --- a/include/linux/resctrl.h
> > +++ b/include/linux/resctrl.h
> > @@ -281,6 +281,7 @@ enum resctrl_schema_fmt {
> > * @mbm_cfg_mask: Bandwidth sources that can be tracked when bandwidth
> > * monitoring events can be configured.
> > * @cdp_capable: Is the CDP feature available on this resource
> > + * @arch_debug_info: Debugfs info directory for architecture use
> > */
> > struct rdt_resource {
> > int rid;
> > @@ -297,6 +298,7 @@ struct rdt_resource {
> > enum resctrl_schema_fmt schema_fmt;
> > unsigned int mbm_cfg_mask;
> > bool cdp_capable;
> > + struct dentry *arch_debug_info;
> > };
>
> ok ... but maybe not quite exactly (more below)
Would have been useful with the "always create directories" approach.
As you point out below the name is problematic. Would need separate
entries for control and monitor resources like RDT_RESOURCE_L3.
I don't think it is useful in the "only make directories when requested
by architecture" mode.
> >
> > /*
> > diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
> > index ed4fc45da346..48c587201fb6 100644
> > --- a/fs/resctrl/rdtgroup.c
> > +++ b/fs/resctrl/rdtgroup.c
> > @@ -4274,6 +4274,8 @@ void resctrl_offline_cpu(unsigned int cpu)
> > */
> > int resctrl_init(void)
> > {
> > + struct dentry *debuginfodir;
> > + struct rdt_resource *r;
> > int ret = 0;
> >
> > seq_buf_init(&last_cmd_status, last_cmd_status_buf,
> > @@ -4320,6 +4322,12 @@ int resctrl_init(void)
> > */
> > debugfs_resctrl = debugfs_create_dir("resctrl", NULL);
> >
> > + /* Create debug info directories for each resource */
> > + debuginfodir = debugfs_create_dir("info", debugfs_resctrl);
> > +
> > + for_each_rdt_resource(r)
> > + r->arch_debug_info = debugfs_create_dir(r->name, debuginfodir);
>
> This ignores (*) several of the boundaries my response aimed to establish.
>
> Here are some red flags:
> - This creates the resource named directory and hands off that pointer to the
> arch. As I mentioned the arch should not have control over resctrl's debugfs.
> I believe this is the type of information that should be in control of resctrl fs
> since, as I mentioned, resctrl fs may need to add debugging that mirrors /sys/fs/resctrl.
> - Blindly creating these directories (a) without the resource even existing on the
> system, and (b) without being used/requested by the architecture does not create a good
> interface in my opinion. User space will see a bunch of empty directories
> associated with resources that are not present on the system.
> - The directories created do not even match /sys/fs/resctrl/info when it comes
> to the resources. Note that the directories within /sys/fs/resctrl/info are created
> from the schema for control resources and appends _MON to monitor resources. Like
> I mentioned in my earlier response there should ideally be space for a future
> resctrl fs extension to mirror layout of /sys/fs/resctrl for resctrl fs debug
> in debugfs. This solution ignores all of that.
>
> I still think that the architecture should request the debugfs directory from resctrl fs.
> This avoids resctrl fs needing to create directories/files that are never used and
> does not present user space with an empty tree. Considering that the new PERF_PKG
> resource may not come online until resctrl mount this should be something that can be
> called at any time.
>
> One possibility, that supports intended use while keeping the door open to support
> future resctrl fs use of the debugfs, could be a new resctrl fs function,
> for example resctrl_create_mon_resource_debugfs(struct rdt_resource *r), that will initialize
> rdt_resource::arch_debug_info(*) to point to the dentry of newly created
> /sys/kernel/debug/resctrl/info/<rdt_resource::name>_MON/arch_debug_name_TBD *if*
> the associated resource is capable of monitoring ... or do you think an architecture
> may want to add debugging information before a resource is discovered/enabled?
> If doing this then rdt_resource::arch_debug_info is no longer appropriate since it needs
> to be specific to the monitoring resource. Perhaps then rdt_resource::arch_mon_debugfs
> that would eventually live in [1]?
>
> This is feeling rushed and I am sharing some top of mind ideas. I will give this
> more thought.
>
> Reinette
>
> [1] https://lore.kernel.org/lkml/cb8425c73f57280b0b4f22e089b2912eede42f7a.1747349530.git.babu.moger@amd.com/
>
> (*) I have now asked several times to stop ignoring feedback. This should not even
> be necessary in the first place. I do not require you to agree with me and I do not claim
> to always be right, please just stop ignoring feedback. The way forward I plan to ignore
> messages that ignores feedback.
So here's a second PoC. Takes into account all of the points you make
above with the following adjustments:
1) Not adding the rdt_resource::arch_mon_debugfs field. Just returning
the "struct dentry *" looks to be adequate for existing use case.
Having the pointer in "struct resource" would be useful if some future
use case needed to access the debugfs locations from calls to
architecture code that pass in the rdt_resource pointer. Could be
added if ever needed.
2) I can't envision a need for debugfs entries for resources
pre-discovery, or when not enabled. So keep things simple for
now.
3) I think the function name resctrl_debugfs_mon_info_mkdir() is a bit
more descriptive (it is making a directory and we usually have such
functions include "mkdir" in the name).
-Tony
---
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 8bec8f766b01..771e69c0c5c1 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -564,6 +564,12 @@ void resctrl_arch_reset_all_ctrls(struct rdt_resource *r);
extern unsigned int resctrl_rmid_realloc_threshold;
extern unsigned int resctrl_rmid_realloc_limit;
+/**
+ * resctrl_debugfs_mon_info_mkdir() - Create a debugfs info directory.
+ * @r: Resource (must be mon_capable).
+ */
+struct dentry *resctrl_debugfs_mon_info_mkdir(struct rdt_resource *r);
+
int resctrl_init(void);
void resctrl_exit(void);
diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
index 8d094a3acf2f..0f11b8d0ce0b 100644
--- a/fs/resctrl/rdtgroup.c
+++ b/fs/resctrl/rdtgroup.c
@@ -4344,6 +4344,22 @@ int resctrl_init(void)
return ret;
}
+struct dentry *resctrl_debugfs_mon_info_mkdir(struct rdt_resource *r)
+{
+ static struct dentry *debugfs_resctrl_info;
+ char name[32];
+
+ if (!r->mon_capable)
+ return NULL;
+
+ if (!debugfs_resctrl_info)
+ debugfs_resctrl_info = debugfs_create_dir("info", debugfs_resctrl);
+
+ sprintf(name, "%s_MON", r->name);
+
+ return debugfs_create_dir(name, debugfs_resctrl_info);
+}
+
static bool resctrl_online_domains_exist(void)
{
struct rdt_resource *r;
--
2.49.0
next prev parent reply other threads:[~2025-06-09 18:49 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 22:50 [PATCH v5 00/29] x86/resctrl telemetry monitoring Tony Luck
2025-05-21 22:50 ` [PATCH v5 01/29] x86,fs/resctrl: Consolidate monitor event descriptions Tony Luck
2025-06-04 3:25 ` Reinette Chatre
2025-06-04 16:33 ` Luck, Tony
2025-06-04 18:24 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 02/29] x86,fs/resctrl: Replace architecture event enabled checks Tony Luck
2025-06-04 3:26 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 03/29] x86/resctrl: Remove 'rdt_mon_features' global variable Tony Luck
2025-06-04 3:27 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 04/29] x86,fs/resctrl: Prepare for more monitor events Tony Luck
2025-05-23 9:00 ` Peter Newman
2025-05-23 15:57 ` Luck, Tony
2025-06-04 3:29 ` Reinette Chatre
2025-06-07 0:45 ` Fenghua Yu
2025-06-08 21:59 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 05/29] x86/rectrl: Fake OOBMSM interface Tony Luck
2025-05-23 23:38 ` Reinette Chatre
2025-05-27 20:25 ` [PATCH v5 05/29 UPDATED] x86/resctrl: " Tony Luck
2025-05-21 22:50 ` [PATCH v5 06/29] x86,fs/resctrl: Improve domain type checking Tony Luck
2025-06-04 3:31 ` Reinette Chatre
2025-06-04 22:58 ` Luck, Tony
2025-06-04 23:40 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 07/29] x86,fs/resctrl: Rename some L3 specific functions Tony Luck
2025-06-04 3:32 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 08/29] x86/resctrl: Move L3 initialization out of domain_add_cpu_mon() Tony Luck
2025-05-21 22:50 ` [PATCH v5 09/29] x86,fs/resctrl: Refactor domain_remove_cpu_mon() ready for new domain types Tony Luck
2025-06-04 3:32 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 10/29] x86/resctrl: Change generic domain functions to use struct rdt_domain_hdr Tony Luck
2025-05-22 0:01 ` Keshavamurthy, Anil S
2025-05-22 0:15 ` Luck, Tony
2025-06-04 3:37 ` Reinette Chatre
2025-06-07 0:52 ` Fenghua Yu
2025-06-08 22:02 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 11/29] x86,fs/resctrl: Rename struct rdt_mon_domain and rdt_hw_mon_domain Tony Luck
2025-06-04 3:40 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 12/29] fs/resctrl: Make event details accessible to functions when reading events Tony Luck
2025-05-21 22:50 ` [PATCH v5 13/29] x86,fs/resctrl: Handle events that can be read from any CPU Tony Luck
2025-06-04 3:42 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 14/29] x86,fs/resctrl: Support binary fixed point event counters Tony Luck
2025-06-04 3:49 ` Reinette Chatre
2025-06-06 16:25 ` Luck, Tony
2025-06-06 16:56 ` Reinette Chatre
2025-06-10 15:16 ` Dave Martin
2025-06-10 15:54 ` Luck, Tony
2025-06-12 16:19 ` Dave Martin
2025-05-21 22:50 ` [PATCH v5 15/29] fs/resctrl: Add an architectural hook called for each mount Tony Luck
2025-06-04 3:49 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 16/29] x86/resctrl: Add and initialize rdt_resource for package scope core monitor Tony Luck
2025-05-21 22:50 ` [PATCH v5 17/29] x86/resctrl: Discover hardware telemetry events Tony Luck
2025-06-04 3:53 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 18/29] x86/resctrl: Count valid telemetry aggregators per package Tony Luck
2025-06-04 3:54 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 19/29] x86/resctrl: Complete telemetry event enumeration Tony Luck
2025-06-04 4:05 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 20/29] x86,fs/resctrl: Fill in details of Clearwater Forest events Tony Luck
2025-06-04 3:57 ` Reinette Chatre
2025-06-07 0:57 ` Fenghua Yu
2025-06-08 22:05 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 21/29] x86/resctrl: x86/resctrl: Read core telemetry events Tony Luck
2025-06-04 4:02 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 22/29] x86,fs/resctrl: Handle domain creation/deletion for RDT_RESOURCE_PERF_PKG Tony Luck
2025-06-04 4:06 ` Reinette Chatre
2025-06-07 0:54 ` Fenghua Yu
2025-06-08 22:03 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 23/29] x86/resctrl: Enable RDT_RESOURCE_PERF_PKG Tony Luck
2025-05-21 22:50 ` [PATCH v5 24/29] x86/resctrl: Add energy/perf choices to rdt boot option Tony Luck
2025-06-04 4:10 ` Reinette Chatre
2025-06-06 23:55 ` Fenghua Yu
2025-06-08 21:52 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 25/29] x86/resctrl: Handle number of RMIDs supported by telemetry resources Tony Luck
2025-06-04 4:13 ` Reinette Chatre
2025-05-21 22:50 ` [PATCH v5 26/29] x86,fs/resctrl: Move RMID initialization to first mount Tony Luck
2025-05-21 22:50 ` [PATCH v5 27/29] fs/resctrl: Add file system mechanism for architecture info file Tony Luck
2025-06-04 4:15 ` Reinette Chatre
2025-06-06 0:09 ` Luck, Tony
2025-06-06 16:26 ` Reinette Chatre
2025-06-06 17:30 ` Luck, Tony
2025-06-06 21:14 ` Reinette Chatre
2025-06-09 18:49 ` Luck, Tony [this message]
2025-06-09 22:39 ` Reinette Chatre
2025-06-09 23:34 ` Luck, Tony
2025-06-10 0:30 ` Reinette Chatre
2025-06-10 18:48 ` Luck, Tony
2025-05-21 22:50 ` [PATCH v5 28/29] x86/resctrl: Add info/PERF_PKG_MON/status file Tony Luck
2025-05-21 22:50 ` [PATCH v5 29/29] x86/resctrl: Update Documentation for package events Tony Luck
2025-05-28 17:21 ` [PATCH v5 00/29] x86/resctrl telemetry monitoring Reinette Chatre
2025-05-28 21:38 ` Luck, Tony
2025-05-28 22:21 ` Reinette Chatre
2025-06-13 16:57 ` James Morse
2025-06-13 18:50 ` 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=aEcsxjWroliWf3G0@agluck-desk3 \
--to=tony.luck@intel.com \
--cc=Dave.Martin@arm.com \
--cc=anil.s.keshavamurthy@intel.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 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).