linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Grant <al.grant@foss.arm.com>
To: John Garry <john.garry@huawei.com>,
	Andrew Kilroy <andrew.kilroy@arm.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	acme@kernel.org, irogers@google.com, ak@linux.intel.com
Cc: Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>
Subject: Re: [RFC PATCH v2 0/5] topdown with metrics
Date: Thu, 20 Jan 2022 16:22:37 +0000	[thread overview]
Message-ID: <b82a3b6a-ec02-09ff-8630-e7647491470c@foss.arm.com> (raw)
In-Reply-To: <7cd7bd11-4900-81c4-de84-6e5fc63ec87c@huawei.com>

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

  reply	other threads:[~2022-01-20 16:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-10 12:37 [PATCH v2 0/2] perf vendor events: Arm Neoverse N2 Andrew Kilroy
2021-12-10 12:37 ` [PATCH v2 1/2] perf vendor events: For the " Andrew Kilroy
2021-12-10 13:21   ` John Garry
2021-12-14 18:42     ` [RFC PATCH 0/1] topdown with metrics Andrew Kilroy
2021-12-14 18:42       ` [RFC PATCH 1/1] perf arm64: Implement --topdown " Andrew Kilroy
2021-12-14 20:32         ` Ian Rogers
2021-12-15 10:38           ` James Clark
2021-12-15 10:52           ` John Garry
2021-12-15 12:38             ` Andrew Kilroy
2021-12-15 12:53               ` John Garry
2022-01-06 16:33                 ` Andrew Kilroy
2022-01-06 18:24                   ` John Garry
2022-01-11 15:07                     ` [RFC PATCH v2 0/5] topdown " Andrew Kilroy
2022-01-11 15:07                       ` [RFC PATCH v2 1/5] perf stat: Implement --topdown " Andrew Kilroy
2022-01-28 13:44                         ` John Garry
2022-01-11 15:07                       ` [RFC PATCH v2 2/5] perf stat: Topdown kernel events setup function Andrew Kilroy
2022-01-11 15:07                       ` [RFC PATCH v2 3/5] perf stat: Topdown json metrics " Andrew Kilroy
2022-01-11 15:07                       ` [RFC PATCH v2 4/5] perf stat: Detect if topdown kernel events supported Andrew Kilroy
2022-01-11 15:07                       ` [RFC PATCH v2 5/5] perf stat: Ensure only topdown kernel events used on x86 Andrew Kilroy
2022-01-20  9:26                       ` [RFC PATCH v2 0/5] topdown with metrics John Garry
2022-01-20 16:22                         ` Al Grant [this message]
2022-01-27 11:42                         ` Andrew Kilroy
2022-02-08 15:58                           ` Andrew Kilroy
2021-12-20 17:21             ` [RFC PATCH 1/1] perf arm64: Implement --topdown " Andrew Kilroy
2021-12-21 14:03               ` Andi Kleen
2022-01-27 11:11                 ` Andrew Kilroy
2021-12-17 10:19         ` John Garry
2021-12-21 14:31           ` Andrew Kilroy
2022-01-05 16:58           ` Andrew Kilroy
2022-01-28 18:00             ` John Garry
2021-12-10 12:37 ` [PATCH v2 2/2] perf vendor events: Rename arm64 arch std event files Andrew Kilroy
2021-12-10 13:46   ` John Garry
2021-12-10 19:01     ` Arnaldo Carvalho de Melo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b82a3b6a-ec02-09ff-8630-e7647491470c@foss.arm.com \
    --to=al.grant@foss.arm.com \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrew.kilroy@arm.com \
    --cc=irogers@google.com \
    --cc=john.garry@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=namhyung@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).