From: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
Tony Luck <tony.luck@intel.com>, Babu Moger <babu.moger@amd.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>,
Drew Fustini <dfustini@baylibre.com>,
"Dave Martin" <Dave.Martin@arm.com>,
Chen Yu <yu.c.chen@intel.com>, <x86@kernel.org>,
<linux-kernel@vger.kernel.org>, <patches@lists.linux.dev>
Subject: Re: [PATCH v5 1/4 UPDATED] x86,fs/resctrl: Consolidate monitor event descriptions
Date: Wed, 4 Jun 2025 15:41:07 -0700 [thread overview]
Message-ID: <2953c1ec-cd92-490e-9b7a-04b10fb98e14@intel.com> (raw)
In-Reply-To: <9e8c9810-1b5c-4e30-8b10-c3702810b529@intel.com>
On 6/4/2025 3:30 PM, Reinette Chatre wrote:
> Hi Anil,
>
> On 6/4/25 3:21 PM, Keshavamurthy, Anil S wrote:
>> On 6/4/2025 2:22 PM, Tony Luck wrote:
> ...
>
>>> diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h
>>> index 9a8cf6f11151..71963255ad36 100644
>>> --- a/fs/resctrl/internal.h
>>> +++ b/fs/resctrl/internal.h
>>> @@ -52,19 +52,26 @@ static inline struct rdt_fs_context *rdt_fc2context(struct fs_context *fc)
>>> }
>>> /**
>>> - * struct mon_evt - Entry in the event list of a resource
>>> + * struct mon_evt - Description of a monitor event
>>> * @evtid: event id
>>> + * @rid: index of the resource for this event
>>> * @name: name of the event
>>> * @configurable: true if the event is configurable
>>> - * @list: entry in &rdt_resource->evt_list
>>> + * @enabled: true if the event is enabled
>>> */
>>> struct mon_evt {
>>> enum resctrl_event_id evtid;
>>> + enum resctrl_res_level rid;
>>> char *name;
>>> bool configurable;
>>> - struct list_head list;
>>> + bool enabled;
>>> };
>>> +extern struct mon_evt mon_event_all[QOS_NUM_EVENTS];
>>> +
>>> +#define for_each_mon_event(mevt) for (mevt = &mon_event_all[QOS_FIRST_EVENT]; \
>>> + mevt < &mon_event_all[QOS_NUM_EVENTS]; mevt++)
>>> +
>>> /**
>>> * struct mon_data - Monitoring details for each event file.
>>> * @list: Member of the global @mon_data_kn_priv_list list.
> ...
>
>>> diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c
>>> index bde2801289d3..90093e54a279 100644
>>> --- a/fs/resctrl/monitor.c
>>> +++ b/fs/resctrl/monitor.c
>>> @@ -842,38 +842,39 @@ static void dom_data_exit(struct rdt_resource *r)
>>> mutex_unlock(&rdtgroup_mutex);
>>> }
>>> -static struct mon_evt llc_occupancy_event = {
>>> - .name = "llc_occupancy",
>>> - .evtid = QOS_L3_OCCUP_EVENT_ID,
>>> -};
>>> -
>>> -static struct mon_evt mbm_total_event = {
>>> - .name = "mbm_total_bytes",
>>> - .evtid = QOS_L3_MBM_TOTAL_EVENT_ID,
>>> -};
>>> -
>>> -static struct mon_evt mbm_local_event = {
>>> - .name = "mbm_local_bytes",
>>> - .evtid = QOS_L3_MBM_LOCAL_EVENT_ID,
>>> -};
>>> -
>>> /*
>>> - * Initialize the event list for the resource.
>>> - *
>>> - * Note that MBM events are also part of RDT_RESOURCE_L3 resource
>>> - * because as per the SDM the total and local memory bandwidth
>>> - * are enumerated as part of L3 monitoring.
>>> + * All available events. Architecture code marks the ones that
>>> + * are supported by a system using resctrl_enable_mon_event()
>>> + * to set .enabled.
>>> */
>>> -static void l3_mon_evt_init(struct rdt_resource *r)
>>> +struct mon_evt mon_event_all[QOS_NUM_EVENTS] = {
>>> + [QOS_L3_OCCUP_EVENT_ID] = {
>>> + .name = "llc_occupancy",
>>> + .evtid = QOS_L3_OCCUP_EVENT_ID,
>>> + .rid = RDT_RESOURCE_L3,
>>> + },
>>> + [QOS_L3_MBM_TOTAL_EVENT_ID] = {
>>> + .name = "mbm_total_bytes",
>>> + .evtid = QOS_L3_MBM_TOTAL_EVENT_ID,
>>> + .rid = RDT_RESOURCE_L3,
>>> + },
>>> + [QOS_L3_MBM_LOCAL_EVENT_ID] = {
>>> + .name = "mbm_local_bytes",
>>> + .evtid = QOS_L3_MBM_LOCAL_EVENT_ID,
>>> + .rid = RDT_RESOURCE_L3,
>>> + },
>>> +};
>> As we start adding many more events to this struct(including region aware specific events), this this becomes too stressful on the eyes to read.....can you consider simplifying this with #define something like below in your next version? NOTE: For the feature that I am adding along with Chen Yu, we started to define a macro as shown below.
>>
>> #define MON_EVENT(_id, _name, _res) \
>> [_id] = { \
>> .name = _name, \
>> .evtid = _id, \
>> .rid = _res, \
>> }
>>
>> Above #define can to into include/linux/resctrl_types.h file and the above code reduces to using MON_EVENT as shown below.
> Any reason why the events need to leak outside resctrl fs? At the moment it is kept
> inside resctrl fs with helpers for only those properties (not descriptions!) that
> can/should be set by archs. Enabling arch full control of the event is not ideal
> since many of the properties are required to be the same across all archs and
> dictate the user interface that is ABI.
>
> Reinette
Sorry, I just picked a random header file there....ignore that part but
my real suggestion was to reduce the lines when declaring "struct
mon_evt mon_event_all[]" with above #define so more events can fit in
one screen when viewing the code.
next prev parent reply other threads:[~2025-06-04 22:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 21:22 [PATCH v5 0/4 UPDATED] AET patches updated with Reinette feedback Tony Luck
2025-06-04 21:22 ` [PATCH v5 1/4 UPDATED] x86,fs/resctrl: Consolidate monitor event descriptions Tony Luck
2025-06-04 22:21 ` Keshavamurthy, Anil S
2025-06-04 22:30 ` Reinette Chatre
2025-06-04 22:41 ` Keshavamurthy, Anil S [this message]
2025-06-04 22:47 ` Luck, Tony
2025-06-04 21:22 ` [PATCH v5 2/4 UPDATED] x86,fs/resctrl: Replace architecture event enabled checks Tony Luck
2025-06-04 21:22 ` [PATCH v5 3/4 UPDATED] x86/resctrl: Remove 'rdt_mon_features' global variable Tony Luck
2025-06-04 21:22 ` [PATCH v5 4/4 UPDATED] x86,fs/resctrl: Prepare for more monitor events Tony Luck
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=2953c1ec-cd92-490e-9b7a-04b10fb98e14@intel.com \
--to=anil.s.keshavamurthy@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=reinette.chatre@intel.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
all inboxes | Powered by JetHome®