From: Andi Kleen <ak@linux.intel.com>
To: Ian Rogers <irogers@google.com>
Cc: Namhyung Kim <namhyung@kernel.org>, linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v9 3/4] perf script: Fix perf script -F +metric
Date: Thu, 8 Aug 2024 13:18:17 -0700 [thread overview]
Message-ID: <ZrUoCRu4HGoROUs2@tassilo> (raw)
In-Reply-To: <CAP-5=fVZ0_orgpLcG492WtjW05QWu2Mbnuv=_NKweouVXq2icA@mail.gmail.com>
>
> Fwiw, not acked-by me. Repeating my comments below:
Let me just point out that you broke it in the first place.
A little more enthusiasm in handling regressions would be appreciated.
> > > diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> > > index c16224b1fef3..cb63507af839 100644
> > > --- a/tools/perf/builtin-script.c
> > > +++ b/tools/perf/builtin-script.c
> > > @@ -335,7 +335,6 @@ struct evsel_script {
> > > FILE *fp;
> > > u64 samples;
> > > /* For metric output */
> > > - u64 val;
> > > int gnum;
>
> We're globally assuming properties of events assuming leader sampling.
> gnum shouldn't exist. The assumptions will be invalid when leader
> sampling isn't enabled.
This is checked for now, see the earlier discussion.
> > > + if (!(leader->core.attr.read_format & PERF_FORMAT_GROUP) ||
> > > + !(leader->core.attr.sample_type & PERF_SAMPLE_READ)) {
> > > + if (!printed)
> > > + fprintf(stderr, "perf script: -F metric requires {}:S for groups leader sampling\n");
> > > + printed = 1;
> > > + return;
> > > + }
> > > + /*
> > > + * Always use the first entry as storage because the leader sampling
> > > + * groups are contiguous and there's no need to handle multiple indexes
> > > + * for anything.
> > > + */
> > > + evsel->stats->aggr[0].counts.val = val;
>
> Updating counts needs perf_stat_process_counter to update the
> aggregation. How does sample->cpu given below relate to aggr[0] here?
> This and the comment above are a hack liable to break in anything but
> straightforward circumstances. See:
> https://lore.kernel.org/lkml/20240720074552.1915993-2-irogers@google.com/
> on how to handle this.
Your patch is based on a fundamental misunderstanding on the perf script
metrics use model, see below.
>
> > > if (evsel_script(leader)->gnum == leader->core.nr_members) {
> > > for_each_group_member (ev2, leader) {
> > > perf_stat__print_shadow_stats(&stat_config, ev2,
> > > - evsel_script(ev2)->val,
> > > - sample->cpu,
> > > + evsel->stats->aggr[0].counts.val,
> > > + 0,
>
> Similarly this hard coded and unexplained constant.
There's a comment just on top of it explaining it:
/*
* Always use the first entry as storage because the leader sampling
* groups are contiguous and there's no need to handle multiple indexes
* for anything.
*/
>
> > > &ctx,
> > > NULL);
> > > }
> > > @@ -2325,6 +2337,20 @@ static void process_event(struct perf_script *script,
> > > fflush(fp);
> > > }
> > >
> > > +static void check_metric_conflict(void)
> > > +{
> > > + int i;
> > > + /*
> > > + * Avoid conflict with the aggregation mode used for the metric printing.
> > > + */
>
> Why is it a conflict, why not support aggregation modes?
I thought I had explained that before.
perf script has two touch point with perf stat output code: one is this one
(for metrics on sampling group) and the other is for perf stat record / script
None of them actually support aggregation because perf script as a
general rule doesn't aggregate, it only handles single events.
But the later one forces AGGR_NONE which doesn't work with the mode the group
output uses.
This feature is only to report the metric state for a single sampling period
and group as explained in the original commit [1]
If you want to aggregate multiple sample periods you need a lot the
machinery from perf report, which doesn't make sense to duplicate
in perf script.
[1] https://www.uwsg.indiana.edu/hypermail/linux/kernel/1712.0/04705.html
-Andi
next prev parent reply other threads:[~2024-08-08 20:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 23:18 [PATCH v9 1/4] Create source symlink in perf object dir Andi Kleen
2024-08-07 23:18 ` [PATCH v9 2/4] perf test: Support external tests for separate objdir Andi Kleen
2024-08-07 23:18 ` [PATCH v9 3/4] perf script: Fix perf script -F +metric Andi Kleen
2024-08-08 5:18 ` Namhyung Kim
2024-08-08 18:09 ` Ian Rogers
2024-08-08 20:18 ` Andi Kleen [this message]
2024-08-09 15:00 ` Ian Rogers
2024-08-07 23:18 ` [PATCH v9 4/4] Add a test case for " Andi Kleen
2024-11-25 17:25 ` [PATCH v9 1/4] Create source symlink in perf object dir Luca Ceresoli
2024-11-25 19:12 ` Andi Kleen
2024-11-26 7:34 ` Luca Ceresoli
2025-04-09 17:43 ` Florian Fainelli
2025-04-09 17:59 ` Florian Fainelli
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=ZrUoCRu4HGoROUs2@tassilo \
--to=ak@linux.intel.com \
--cc=irogers@google.com \
--cc=linux-perf-users@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.