linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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 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).