All of lore.kernel.org
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: 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>,
	"Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.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 v5 27/29] fs/resctrl: Add file system mechanism for architecture info file
Date: Mon, 9 Jun 2025 17:30:34 -0700	[thread overview]
Message-ID: <71a51672-4cc7-47eb-bbbb-a3195189becc@intel.com> (raw)
In-Reply-To: <SJ1PR11MB60834D5E5D78CE229D04204FFC6BA@SJ1PR11MB6083.namprd11.prod.outlook.com>



On 6/9/25 4:34 PM, Luck, Tony wrote:
> Reinette,
> 
> Trimming to focus on why I was confused by your message.
> 
>>> 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 
> 
> What exactly is this dentry pointing to? I was mistakenly of the impression that it was a directory.

Yes, it has been directory since https://lore.kernel.org/lkml/9eb9a466-2895-405a-91f7-cda75e75f7ae@intel.com/
If your impression was indeed that it was a directory then why did your patch not
create a directory?

I am now going to repeat what I said in https://lore.kernel.org/lkml/9eb9a466-2895-405a-91f7-cda75e75f7ae@intel.com/

> 
> Now I think that you intend it to be a single file with a name chosen by filesystem code.
> 
> Is that right?
Not what I have been saying, no.

> 
> If so, there needs to be "umode_t mode" and "struct file_operations *fops" arguments
> for architecture to say whether this file is readable, writeable, and most importantly
> to specify the architecture functions to be called when the user accesses this file.
> 
> With added "mode" and "fops" arguments this proposal meets my needs.
> 
> Choosing the exact string for the "arch_debug_name_TBD" file name that

This should be a directory, a directory owned by the arch where it can create
debug infrastructure required by arch. The directory name chosen and
assigned by resctrl fs, while arch has freedom to create more directories
and add files underneath it. Goal is to isolate all arch specific debug to
a known location.

Again, we need to prepare for resctrl fs to potentially use debugfs for its own
debug and when it does this the expectation is that the layout will mirror
/sys/fs/resctrl. Creating a directory /sys/kernel/debug/resctrl/info/<rdt_resource::name>_MON
and then handing it off to the arch goes *against* this. It gives arch
control over a directory that should be owned by resctrl fs.

What I have been trying to propose is that resctrl fs create a directory
/sys/kernel/debug/resctrl/info/<rdt_resource::name>_MON/arch_debug_name_TBD and hand
a dentry pointer to it to the arch where it can do what is needed to support its debugging needs.
Isn't this exactly what I wrote in the snippet above? Above you respond with
statement that you were under impression that it was a directory ... and then
send a patch that does something else. I am so confused. Gaslighting is
beneath you.

> will be given to any other users needs some thought. I was planning on
> simply "status" since the information that I want to convey is read-only
> status about each of the telemetry collection aggregators. But that feels
> like it might be limiting if a future use includes any control options by
> providing a writable file.

The file containing the debug information for this feature will be added within
the directory that we are talking about here.

Reinette

  reply	other threads:[~2025-06-10  0:30 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
2025-06-09 22:39               ` Reinette Chatre
2025-06-09 23:34                 ` Luck, Tony
2025-06-10  0:30                   ` Reinette Chatre [this message]
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=71a51672-4cc7-47eb-bbbb-a3195189becc@intel.com \
    --to=reinette.chatre@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=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 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.