From: Namhyung Kim <namhyung@kernel.org>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: irogers@google.com, linux-perf-users@vger.kernel.org,
linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH v5 6/8] perf report: Add --latency flag
Date: Tue, 11 Feb 2025 09:42:28 -0800 [thread overview]
Message-ID: <Z6uMBAG0hePL9JV3@google.com> (raw)
In-Reply-To: <CACT4Y+brgj5vRoxQtZ76hUVcHWUJJ2u_8n89EwuTAoyXXbGDCw@mail.gmail.com>
On Tue, Feb 11, 2025 at 09:42:16AM +0100, Dmitry Vyukov wrote:
> On Tue, 11 Feb 2025 at 02:02, Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Fri, Feb 07, 2025 at 08:23:58AM +0100, Dmitry Vyukov wrote:
> > > On Fri, 7 Feb 2025 at 04:44, Namhyung Kim <namhyung@kernel.org> wrote:
[SNIP]
> > > > > @@ -3547,10 +3549,15 @@ static int __hpp_dimension__add_output(struct perf_hpp_list *list,
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -int hpp_dimension__add_output(unsigned col)
> > > > > +int hpp_dimension__add_output(unsigned col, bool implicit)
> > > > > {
> > > > > + struct hpp_dimension *hd;
> > > > > +
> > > > > BUG_ON(col >= PERF_HPP__MAX_INDEX);
> > > > > - return __hpp_dimension__add_output(&perf_hpp_list, &hpp_sort_dimensions[col]);
> > > > > + hd = &hpp_sort_dimensions[col];
> > > > > + if (implicit && !hd->was_taken)
> > > > > + return 0;
> > > >
> > > > I don't think you need these implicit and was_taken things.
> > > > Just removing from the sort list when it's unregistered seems to work.
> > > >
> > > > ---8<---
> > > > @@ -685,6 +685,7 @@ void perf_hpp_list__prepend_sort_field(struct perf_hpp_list *list,
> > > > static void perf_hpp__column_unregister(struct perf_hpp_fmt *format)
> > > > {
> > > > list_del_init(&format->list);
> > > > + list_del_init(&format->sort_list);
> > > > fmt_free(format);
> > > > }
> > > >
> > > > ---8<---
> > >
> > > It merely suppresses the warning, but does not work the same way. See
> > > this for details:
> > > https://lore.kernel.org/all/CACT4Y+ZREdDL7a+DMKGFGae1ZjX1C8uNRwCGF0c8iUJtTTq0Lw@mail.gmail.com/
> >
> > But I think it's better to pass --latency option rather than adding it
> > to -s option. If you really want to have specific output fields, then
> > please use -F latency,sym instead.
> >
> > Also I've realized that it should add one sort key in setup_overhead()
> > to support hierarchy mode properly. Something like this?
> >
> > Thanks,
> > Namhyung
> >
> >
> > ---8<---
> > diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> > index 2b6023de7a53ae2e..329c2e9bbc69a725 100644
> > --- a/tools/perf/util/sort.c
> > +++ b/tools/perf/util/sort.c
> > @@ -3817,22 +3817,15 @@ static char *setup_overhead(char *keys)
> > return keys;
> >
> > if (symbol_conf.prefer_latency) {
> > - keys = prefix_if_not_in("overhead", keys);
> > - keys = prefix_if_not_in("latency", keys);
> > - if (symbol_conf.cumulate_callchain) {
> > - keys = prefix_if_not_in("overhead_children", keys);
> > + if (symbol_conf.cumulate_callchain)
> > keys = prefix_if_not_in("latency_children", keys);
> > - }
> > - } else if (!keys || (!strstr(keys, "overhead") &&
> > - !strstr(keys, "latency"))) {
> > - if (symbol_conf.enable_latency)
> > + else
> > keys = prefix_if_not_in("latency", keys);
> > - keys = prefix_if_not_in("overhead", keys);
> > - if (symbol_conf.cumulate_callchain) {
> > - if (symbol_conf.enable_latency)
> > - keys = prefix_if_not_in("latency_children", keys);
> > + } else {
> > + if (symbol_conf.cumulate_callchain)
> > keys = prefix_if_not_in("overhead_children", keys);
> > - }
> > + else
> > + keys = prefix_if_not_in("overhead", keys);
> > }
> >
> > return keys;
>
>
> Have I decoded the patch correctly?
>
> if (symbol_conf.prefer_latency) {
> if (symbol_conf.cumulate_callchain)
> keys = prefix_if_not_in("latency_children", keys);
> else
> keys = prefix_if_not_in("latency", keys);
> } else {
> if (symbol_conf.cumulate_callchain)
> keys = prefix_if_not_in("overhead_children", keys);
> else
> keys = prefix_if_not_in("overhead", keys);
> }
>
Yep, that's correct.
> If I decoded the patch correctly, it's not what we want.
>
> For the default prefer_latency case we also want to add overhead, that
> was intentional for the --latency preset. It does not harm, and allows
> to see/compare differences in latency and overhead.
> Again, if a user wants something custom, there is no way to second
> guess all possible intentions. For non-default cases, we just let the
> user say what exactly they want, and we will follow that.
>
> "latency" should be added even if cumulate_callchain.
Please note that it just sets the sort key - which column you want to
order the result. The output fields for overhead and children will be
added in perf_hpp__init() if you remove the 'was_taken' logic. So I
think this change will have the same output with that.
>
> For the !prefer_latency case, we don't want to mess with
> overhead/latency fields if the user specified any of them explicitly.
> Otherwise this convenience part gets in the user's way and does not
> allow them to do what they want. User says "I want X" and perf says
> "screw you, I will give you Y instead, and won't allow you to possibly
> do X".
That's what -F option does. The -s option used to specify how to group
the histogram entries and it will add 'overhead' (and/or 'latency') if
it's not even requested. So I think it's ok to add more output column
when -s option is used.
But unfortunately, using -F and -s together is confusing and change the
meaning of -s option - it now says how it sort the result.
>
> And see above: -F does not work with --hierarchy, so this part is unskippable.
Yep, but I mean it fixes --hierarchy and --latency. I'm thinking of a
way to support -F and --hierarchy in general.
Thanks,
Namhyung
next prev parent reply other threads:[~2025-02-11 17:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 16:27 [PATCH v5 0/8] perf report: Add latency and parallelism profiling Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 1/8] perf report: Add machine parallelism Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 2/8] perf report: Add parallelism sort key Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 3/8] perf report: Switch filtered from u8 to u16 Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 4/8] perf report: Add parallelism filter Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 5/8] perf report: Add latency output field Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 6/8] perf report: Add --latency flag Dmitry Vyukov
2025-02-07 3:44 ` Namhyung Kim
2025-02-07 7:23 ` Dmitry Vyukov
2025-02-11 1:02 ` Namhyung Kim
2025-02-11 8:30 ` Dmitry Vyukov
2025-02-11 8:42 ` Dmitry Vyukov
2025-02-11 17:42 ` Namhyung Kim [this message]
2025-02-11 20:23 ` Dmitry Vyukov
2025-02-12 19:47 ` Namhyung Kim
2025-02-13 9:09 ` Dmitry Vyukov
2025-02-07 3:53 ` Namhyung Kim
2025-02-07 11:42 ` Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 7/8] perf report: Add latency and parallelism profiling documentation Dmitry Vyukov
2025-02-05 16:27 ` [PATCH v5 8/8] perf hist: Shrink struct hist_entry size Dmitry Vyukov
2025-02-06 18:30 ` [PATCH v5 0/8] perf report: Add latency and parallelism profiling Andi Kleen
2025-02-06 18:41 ` Dmitry Vyukov
2025-02-06 18:51 ` Ian Rogers
2025-02-07 3:57 ` Namhyung Kim
2025-02-07 11:44 ` Dmitry Vyukov
2025-02-06 18:57 ` Andi Kleen
2025-02-06 19:07 ` Andi Kleen
2025-02-07 8:16 ` Dmitry Vyukov
2025-02-07 18:30 ` Andi Kleen
2025-02-10 7:17 ` Dmitry Vyukov
2025-02-10 17:11 ` Andi Kleen
2025-02-13 9:09 ` Dmitry Vyukov
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=Z6uMBAG0hePL9JV3@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=dvyukov@google.com \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.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.