[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <abe9801e-074f-4191-b545-97a56855d584@intel.com>
Date: Wed, 13 Aug 2025 21:11:11 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Tony Luck <tony.luck@...el.com>, Fenghua Yu <fenghuay@...dia.com>, "Maciej
Wieczor-Retman" <maciej.wieczor-retman@...el.com>, Peter Newman
<peternewman@...gle.com>, James Morse <james.morse@....com>, Babu Moger
<babu.moger@....com>, Drew Fustini <dfustini@...libre.com>, Dave Martin
<Dave.Martin@....com>, Chen Yu <yu.c.chen@...el.com>
CC: <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
<patches@...ts.linux.dev>
Subject: Re: [PATCH v8 12/32] fs/resctrl: Make event details accessible to
functions when reading events
Hi Tony,
On 8/11/25 11:16 AM, Tony Luck wrote:
> All details about a monitor event are kept in the mon_evt structure.
>
> Upper levels of code only provide the event id to lower levels.
"to lower levels" -> "via the mon_data and rmid_read structures to
the functions finally reading the monitoring data."
>
> But those lower levels need more than just the event id, they need
> the attributes of the event too.
This motivation is weak. If those "lower levels" needed more than what
they have now then existing code will be broken, no? This change is thus
in support of a new requirements and "this is needed" is not a valid
motivation.
Consider something like:
The event id is sufficient for reading existing monitoring event
data that requires programming of event id into MSR when reading
the counter. Reading monitoring data from MMIO requires more
context to be able to read the correct memory. struct mon_evt
is the appropriate place for this event specific context.
>
> Change the mon_data and rmid_read structures to hold a pointer
> to the mon_evt structure instead of just taking a copy of the
> event id.
>
> No functional change.
>
> Signed-off-by: Tony Luck <tony.luck@...el.com>
> ---
Reinette
Powered by blists - more mailing lists