From: Andi Kleen <ak@linux.intel.com>
To: Ian Rogers <irogers@google.com>,
Zhengjun Xing <zhengjun.xing@linux.intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
perry.taylor@intel.com, caleb.biggers@intel.com,
kshipra.bopardikar@intel.com, samantha.alt@intel.com,
ahmad.yasin@intel.com, Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH v3 00/23] Improvements to Intel perf metrics
Date: Tue, 4 Oct 2022 10:28:45 -0700 [thread overview]
Message-ID: <677c6ec7-2e01-635b-dbfb-fbb9280e5b7c@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fXk6sLhZsEs72G4pOuZNzDJLc2Vkkvf+Jv=LXQDHPy8-w@mail.gmail.com>
[cutting down cc list]
On 10/3/2022 8:43 PM, Ian Rogers wrote:
> On Mon, Oct 3, 2022 at 7:16 PM Ian Rogers <irogers@google.com> wrote:
>> For consistency with:
>> https://github.com/intel/perfmon-metrics
>> rename of topdown TMA metrics from Frontend_Bound to tma_frontend_bound.
>>
>> Remove _SMT suffix metrics are dropped as the #SMT_On and #EBS_Mode
>> are correctly expanded in the single main metric. Fix perf expr to
>> allow a double if to be correctly processed.
>>
>> Add all 6 levels of TMA metrics. Child metrics are placed in a group
>> named after their parent allowing children of a metric to be
>> easily measured using the metric name with a _group suffix.
>>
>> Don't drop TMA metrics if they contain topdown events.
>>
>> The ## and ##? operators are correctly expanded.
>>
>> The locate-with column is added to the long description describing a
>> sampling event.
>>
>> Metrics are written in terms of other metrics to reduce the expression
>> size and increase readability.
>>
>> Following this the pmu-events/arch/x86 directories match those created
>> by the script at:
>> https://github.com/intel/event-converter-for-linux-perf/blob/master/download_and_gen.py
>> with updates at:
>> https://github.com/captain5050/event-converter-for-linux-perf
>>
>>
>> v3. Fix a parse metrics test failure due to making metrics referring
>> to other metrics case sensitive - make the cases in the test
>> metric match.
>> v2. Fixes commit message wrt missing mapfile.csv updates as noted by
>> Zhengjun Xing <zhengjun.xing@linux.intel.com>. ScaleUnit is added
>> for TMA metrics. Metrics with topdown events have have a missing
>> slots event added if necessary. The latest metrics at:
>> https://github.com/intel/perfmon-metrics are used, however, the
>> event-converter-for-linux-perf scripts now prefer their own
>> metrics in case of mismatched units when a metric is written in
>> terms of another. Additional testing was performed on broadwell,
>> broadwellde, cascadelakex, haswellx, sapphirerapids and tigerlake
>> CPUs.
> I wrote up a little example of performing a top-down analysis for the
> perf wiki here:
> https://perf.wiki.kernel.org/index.php/Top-Down_Analysis
I did some quick testing.
On Skylake the output of L1 isn't scaled to percent:
$ ./perf stat -M TopdownL1 ~/pmu/pmu-tools/workloads/BC1s
Performance counter stats for '/home/ak/pmu/pmu-tools/workloads/BC1s':
608,066,701 INT_MISC.RECOVERY_CYCLES # 0.32
Bad_Speculation (50.02%)
5,364,230,382 CPU_CLK_UNHALTED.THREAD # 0.48
Retiring (50.02%)
10,194,062,626 UOPS_RETIRED.RETIRE_SLOTS (50.02%)
14,613,100,390 UOPS_ISSUED.ANY (50.02%)
2,928,793,077 IDQ_UOPS_NOT_DELIVERED.CORE # 0.14
Frontend_Bound
# 0.07
Backend_Bound (50.02%)
604,850,703 INT_MISC.RECOVERY_CYCLES (50.02%)
5,357,291,185 CPU_CLK_UNHALTED.THREAD (50.02%)
14,618,285,580 UOPS_ISSUED.ANY (50.02%)
Then if I follow the wiki example here I would expect I need to do
$ ./perf stat -M tma_backend_bound_group ~/pmu/pmu-tools/workloads/BC1s
Cannot find metric or group `tma_backend_bound_group'
but tma_retiring_group doesn't exist. So it seems the methodology isn't
fully consistent everywhere? Perhaps the wiki needs to document the
supported CPUs and also what part of the hierarchy is supported.
Another problem I noticed in the example is that the sample event didn't
specify PEBS, even though it probably should at least on Icelake+ where
every event can be used with less over with PEBS.
Also with all these groups that need to be specified by hand some bash
completion support for groups would be really useful)
-Andi
next prev parent reply other threads:[~2022-10-04 17:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-04 2:15 [PATCH v3 00/23] Improvements to Intel perf metrics Ian Rogers
2022-10-04 2:15 ` [PATCH v3 01/23] perf expr: Allow a double if expression Ian Rogers
2022-10-04 2:15 ` [PATCH v3 02/23] perf test: Adjust case of test metrics Ian Rogers
2022-10-04 2:15 ` [PATCH v3 03/23] perf expr: Remove jevents case workaround Ian Rogers
2022-10-04 2:15 ` [PATCH v3 04/23] perf metrics: Don't scale counts going into metrics Ian Rogers
2022-10-04 2:15 ` [PATCH v3 07/23] perf vendor events: Update Intel broadwell Ian Rogers
2022-10-04 2:15 ` [PATCH v3 10/23] perf vendor events: Update elkhartlake cpuids Ian Rogers
2022-10-04 2:16 ` [PATCH v3 11/23] perf vendor events: Update Intel haswell Ian Rogers
2022-10-04 2:16 ` [PATCH v3 13/23] perf vendor events: Update Intel icelake Ian Rogers
2022-10-04 2:16 ` [PATCH v3 15/23] perf vendor events: Update Intel ivybridge Ian Rogers
2022-10-04 2:16 ` [PATCH v3 17/23] perf vendor events: Update Intel jaketown Ian Rogers
2022-10-04 2:16 ` [PATCH v3 18/23] perf vendor events: Update Intel sandybridge Ian Rogers
2022-10-04 2:16 ` [PATCH v3 20/23] perf vendor events: Update silvermont cpuids Ian Rogers
2022-10-04 2:16 ` [PATCH v3 22/23] perf vendor events: Update Intel tigerlake Ian Rogers
2022-10-04 2:16 ` [PATCH v3 23/23] perf vendor events: Update Intel broadwellde Ian Rogers
2022-10-04 3:43 ` [PATCH v3 00/23] Improvements to Intel perf metrics Ian Rogers
2022-10-04 17:28 ` Andi Kleen [this message]
2022-10-04 17:55 ` Ian Rogers
2022-10-04 18:09 ` Arnaldo Carvalho de Melo
2022-10-04 18:15 ` Andi Kleen
2022-10-04 18:26 ` Arnaldo Carvalho de Melo
2022-10-04 12:09 ` 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=677c6ec7-2e01-635b-dbfb-fbb9280e5b7c@linux.intel.com \
--to=ak@linux.intel.com \
--cc=acme@kernel.org \
--cc=ahmad.yasin@intel.com \
--cc=caleb.biggers@intel.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kshipra.bopardikar@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@kernel.org \
--cc=perry.taylor@intel.com \
--cc=samantha.alt@intel.com \
--cc=zhengjun.xing@linux.intel.com \
/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).