Message-ID: <e6e6e508-bb41-d1c2-384f-1f723c7a36f7@oracle.com>
Date:   Thu, 30 Mar 2023 16:55:36 +0100
From:   John Garry <john.g.garry@...cle.com>
To:     Robin Murphy <robin.murphy@....com>,
        Jing Zhang <renyu.zj@...ux.alibaba.com>,
        Ian Rogers <irogers@...gle.com>, Will Deacon <will@...nel.org>,
        James Clark <james.clark@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ilkka Koskinen <ilkka@...amperecomputing.com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org,
        Shuai Xue <xueshuai@...ux.alibaba.com>,
        Zhuo Song <zhuo.song@...ux.alibaba.com>
Subject: Re: [PATCH RFC 1/4] driver/perf: Add identifier sysfs file for CMN

On 29/03/2023 18:47, Robin Murphy wrote:
>> Do Illka and Robin know that there is such a register that can 
>> identify different CMN versions? Looking forward to your suggestions.
> 
> In principle the "part number" fields from CFGM_PERIPH_ID_0/1 are 
> supposed to identify the model, but for various reasons I'm suspicious 
> of that being unreliable (not least that no actual values are 
> documented, only "configuration-dependent"). That's why I went down the 
> route of making sure we have explicit ACPI/DT identifiers for every model.
> 
> However, the model alone seems either too specific or not specific 
> enough for a jevents identifier. The defined metrics are pretty trivial 
> and should have no real reason not to be common to *any* CMN PMU where 
> the underlying events are present. On the other hand, if we want to get 
> down to the level of specific events in JSON then we'd need to consider 
> the revision as well, since there are several events which only exist on 
> certain revisions of a given model (but often are also common to later 
> models).
> 
> This actually foreshadows a question I was planning to bring up in the 
> context of another driver I'm working on - for this one I would rather 
> like to try using jevents rather than have to maintain another sprawl of 
> event tables in a driver, but it's still going to have the same thing of 
> wanting model/revision matching along the lines of what 
> arm_cmn_event_attr_is_visible() is doing for CMN events. AFAICS this 
> would need jevents to grow a rather more flexible way of encoding and 
> matching identifiers, since having dozens of almost-identical copies of 
> event definitions for every exact identifier value is clearly 
> unworkable.

This sort of problem has not occurred yet as perf tool only supports 
"system" events for a handful of SoCs so far :)

> Does anyone happen to have any thoughts or preferences 
> around how that might be approached?
> 

Currently the perf tool will just match system events based on the exact 
HW identifier and PMU name.

However, if you consider PMCG PMU support as an example of possible area 
of improvement, it has a number of fixed events and a number of IMPDEF 
events. There should be no reason to need to describe in a separate JSON 
those fixed events for every instance of that PMU.

So a simple change would be to teach perf tool that for certain fixed 
events we only need to match based on the PMU name. For others we need 
to match based on some identifier.

If matching based on an identifier still leads to unwieldy amounts of 
tables, then maybe HW identifier wildcard matching may suit, like what 
is done for CPU events.

Thanks,
John

Powered by blists - more mailing lists