linux-kernel - Re: [RFC PATCH v2 0/5] topdown with metrics

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]

Date:   Thu, 20 Jan 2022 16:22:37 +0000
From:   Al Grant <al.grant@...s.arm.com>
To:     John Garry <john.garry@...wei.com>,
        Andrew Kilroy <andrew.kilroy@....com>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        acme@...nel.org, irogers@...gle.com, ak@...ux.intel.com
Cc:     Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>
Subject: Re: [RFC PATCH v2 0/5] topdown with metrics

On 20/01/2022 09:26, John Garry wrote:
> On 11/01/2022 15:07, Andrew Kilroy wrote:
>> This patch series adds the ability for the --topdown option to use
>> metrics (defined in json files in the pmu-events directory) to describe
>> how to calculate and determine the output columns for topdown level 1.
>>
>> For this to work, a number of metrics have to be defined for the
>> relevant processor with the MetricGroup name "TopDownL1".  perf will
>> arrange for the events defined in each metric to be collected, and each
>> metric will be displayed in the output, as if
>>
>>    perf stat -M 'TopDownL1' --metric-only -- exampleapp
>>
>> had been used.
>>
>> Topdown was already implemented where certain kernel events are defined.
>> If these kernel events are defined, the new json metrics behaviour is
>> not used.  The json metrics approach is only used if the kernel events
>> are absent.
>>
>> The last patch in the series disables the json metrics behaviour on x86.
>> This is because of concerns that due to SMT it's not straightforward to
>> express the various formulas as json for certain x86 cpus.  See
> 
> I suppose this solution is ok.
> 
> A concern is that today we only have 1x arm64 platform which actually supports this in mainline.
> 
> Do you have any more which you plan to support?
> 
> I think that it's the frontend bound and fetch_bubble event which doesn't have a standard arm solution.
> 
> Note that I do have a series for perf tool which can read arm cpu pmu sysfs events folder to find events which are implemented (I don't think all required events are mandated) and match that against the common arch events JSON, so that we don't need a JSON definition file for each core implementation from all implementators - this would improve scalability.However a concern is that some events - like inst_spec - have imp def meaning, so may not be good to always use by default for all cores metrics.

Sadly the sysfs list isn't complete, it only includes the events
discoverable from the PMCEIDx registers, and they only cover the
ranges 0x0000-0x003f and 0x4000-0x403f. Although that covers most
events used in standard metrics, it doesn't cover all. Most CPUs
have many more events besides these, and there are now architected
(common) events in the 0x8000 range.

There's a lot to be said for having the kernel expose the complete
list to userspace via sysfs. It would save each userspace tool
needing its own set of vendor-supplied information. But to get
that complete list, the kernel would need the same vendor
information the userspace tools are using now.

(And your concern about the metrics varying even when the same
events are present, is quite valid.)

Al