[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d65b0ecb-61ba-4dde-abe8-666370d3e5d8@intel.com>
Date: Tue, 22 Apr 2025 11:20:34 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: 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>, "Anil
Keshavamurthy" <anil.s.keshavamurthy@...el.com>,
<linux-kernel@...r.kernel.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH v3 12/26] fs/resctrl: Add hook for architecture code to
set monitor event attributes
Hi Tony,
On 4/21/25 12:50 PM, Luck, Tony wrote:
> On Fri, Apr 18, 2025 at 04:11:22PM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 4/7/25 4:40 PM, Tony Luck wrote:
>>> Architecture code knows whether an event can be read from any CPU, or
>>> from a CPU on a specific domain. It also knows what format to use
>>> when printing each event value.
>>>
>>> Add a hook to set mon_event.any_cpu and mon_event.type.
>>
>> If the architecture modifies the output format then the values exposed
>> to user space will look different between architectures. User space will
>> need to know how to parse the data. We do not want user space to need to
>> know which architecture it is running on to determine how to interact with
>> user space so this makes me think that this change needs to be accompanied
>> with a change that exposes the event format to user space.
>
> Would it be enough to include this in Documentation? I.e. add specific
> entries for "core_energy" to say that it is reported as a floating point
> value with unit Joules, and "activity" is reported as a floating point
> value with unit of Farads.
If it is always a floating point, yes, but this patch enables an
architecture to modify output to be different.
>
> Alternatively the filesystem code could convert the fixed point values
> to integer values of micro-Joules and micro-Farads. Then the filesystem
> code can print with "%llu" just like every other event. Would still need
> the Documentation entries to explain the units. This has the limitation
> that some future implementation that measures in greater precision would
> be forced to round to nearest micro-{Joule,Farad}.
I do not think we are talking about the same issue.
>
> File system code controls the formating options available, so options
> for architecture code to break the user interface are limited.
File system gives away the control with this patch, no?
This patch enables the architecture to change the output format. On
one architecture the event may thus be presented as floating point while
on another architecture the event will not be floating point.
Reinette
Powered by blists - more mailing lists