linux-kernel - Re: [PATCH v3 2/7] perf metric: Event "Compat" value supports matching multiple identifiers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c4b2fca8-602d-9c76-90a7-3eafd92da8bc@oracle.com>
Date:   Fri, 2 Jun 2023 17:20:30 +0100
From:   John Garry <john.g.garry@...cle.com>
To:     Jing Zhang <renyu.zj@...ux.alibaba.com>,
        Ian Rogers <irogers@...gle.com>, Will Deacon <will@...nel.org>,
        Shuai Xue <xueshuai@...ux.alibaba.com>,
        Robin Murphy <robin.murphy@....com>
Cc:     James Clark <james.clark@....com>,
        Mike Leach <mike.leach@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Ilkka Koskinen <ilkka@...amperecomputing.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-perf-users@...r.kernel.org,
        Zhuo Song <zhuo.song@...ux.alibaba.com>
Subject: Re: [PATCH v3 2/7] perf metric: Event "Compat" value supports
 matching multiple identifiers

On 01/06/2023 09:58, Jing Zhang wrote:
>>  From checking the driver, it seems that we have model names "arm_cmn600" and "arm_cmn650". Are you saying that "arm_cmn600X" would match for those? I am most curious about how "arm_cmn600X" matches "arm_cmn650".
>>
> Hi John,
> 
>  From patch #1 we have identifiers "arm_cmn600_0" and "arm_cmn650_0" etc. 

ok, I see. Your idea for the cmn driver HW identifier format is odd to 
me. Your HW identifier is a mix of the HW IP model name (from 
arm_cmn_device_data.model_name) with some the kernel revision identifier 
(from cmn_revision). The kernel revision identifier is an enum, and I 
don't think that it is a good idea to expose enum values through sysfs 
files.

I assume that there is some ordering requirement for cmn_revision, 
considering that we have equality operations on the revision in the driver.

> The identifier consists of model_name and revision.
> The compatible value "arm_cmn600;arm_cmn650" can match the identifier "arm_cmn600_0" or "arm_cmn650_0". Maybe the message log
> is not clear enough.
> 
> For example in patch #3 the metric "slc_miss_rate" is a generic metric for cmn-any. So we can define:
> 
> +	{
> +		"MetricName": "slc_miss_rate",
> +		"BriefDescription": "The system level cache miss rate include.",
> +		"MetricGroup": "arm_cmn",
> +		"MetricExpr": "hnf_cache_miss / hnf_slc_sf_cache_access",
> +		"ScaleUnit": "100%",
> +		"Unit": "arm_cmn",
> +		"Compat": "arm_cmn600;arm_cmn650;arm_cmn700;arm_ci700"
> +	},
> 
> 
> It can match identifiers "arm_cmn600_{0,1,2..X}" or "arm_cmn650_{0,1,2..X}" or "arm_cmn700_{0,1,2..X}" or "arm_ci700_{ 0,1,2..X}".
> In other words, it can match all identifiers prefixed with “arm_cmn600” or “arm_cmn650” or “arm_cmn700” or “arm_ci700”.
> 
> If a new model arm_cmn driver with identifier "arm_cmn750_0", it will not be matched, but if a new revision arm_cmn driver with identifier
> "arm_cmn700_4", it can be matched.

OK, I see what you mean. My confusion came about though your commit 
message on this same patch, which did not mention cmn650. I assumed that 
the example event which you were describing was supported for arm_cmn650 
and you intentionally omitted it.

> 
> 
>>> Tokens in Unit field are delimited by ';'.
>> Thanks for taking a stab at solving this problem.
>>
>> I have to admit that I am not the biggest fan of having multiple values to match in the "Compat" value possibly for every event. It doesn't really scale.
>>
>> I would hope that there are at least some events which we are guaranteed to always be present. From what Robin said on the v2 series, for the implementations which we care about, events are generally added per subsequent version. So we should have some base set of fixed events.
>>
>> If we are confident that we have a fixed set of base set of events, can we ensure that those events would not require this compat string which needs each version explicitly stated?
>>
> If we are sure that some events will always exist in subsequent versions, we can set the Compat field to "arm_cmn;arm_ci". After that,
> whether it is a different model or a different revision of the cmn PMU, it will be compatible. That is, it matches all whose identifier
> is prefixed with “arm_cmn” or “arm_ci”.

Sure, we could do something like that. Or if we are super-confident that 
every model and rev will support some event, then we can change perf 
tool to just not check Compat for that event.

> 
> Maybe it's not a perfect solution yet, looking forward to your suggestions.

Well first we need to define kernel HW identifier format. I don't know 
why we don't encode model and revision name, like "cmn650_r1p1". Robin?

Thanks,
John