Re: [PATCH 2/2] perf hist: Fix bogus profiles when filters are enabled

[Dmitry Vyukov]

On Thu, 9 Jan 2025 at 22:59, Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
>
> On Wed, Jan 08, 2025 at 08:36:54AM +0100, Dmitry Vyukov wrote:
> > When a filtered column is not present in the sort order, profiles become
> > arbitrary broken. Filtered and non-filtered entries are collapsed
> > together, and the filtered-by field ends up with a random value (either
> > from a filtered or non-filtered entry). If we end up with filtered
> > entry/value, then the whole collapsed entry will be filtered out and will
> > be missing in the profile. If we end up with non-filtered entry/value,
> > then the overhead value will be wrongly larger (include some subset
> > of filtered out samples).
> >
> > This leads to very confusing profiles. The problem is hard to notice,
> > and if noticed hard to understand. If the filter is for a single value,
> > then it can be fixed by adding the corresponding field to the sort order
> > (provided user understood the problem). But if the filter is for multiple
> > values, it's impossible to fix b/c there is no concept of binary sorting
> > based on filter predicate (we want to group all non-filtered values in
> > one bucket, and all filtered values in another).
> >
> > Examples of affected commands:
> > perf report --tid=123
> > perf report --sort overhead,symbol --comm=foo,bar
> >
> > Fix this by considering filtered status as the highest priority
> > sort/collapse predicate.
>
> Do you mean when you specify filters not in a sort list?
>
> I guess it's an undefined behavior.. probably better to warn users not
> to do that and exit.  The hist entries are built using only the fields
> in the sort list.  Filtering by unspecified fields would be meaningless
> and won't work well IMHO.

We could warn as well, but I do want this feature for:
https://lore.kernel.org/linux-perf-users/CACT4Y+an1LSY15f9MS_vnbaaeeqMf+k4-Dqqfu-zwcUAHFNk=w@xxxxxxxxxxxxxx/T/#t
I think it may be useful for other cases as well, let's discuss the
feature below.
Why won't it work well? At least in my local manual testing, it worked
well. This does make hist built using filtered fields as well.


> > As a side effect this effectively adds a new feature of showing profile
> > where several lines are combined based on arbitrary filtering predicate.
> > For example, showing symbols from binaries foo and bar combined together,
> > but not from other binaries; or showing combined overhead of several
> > particular threads.
>
> I'm not sure I'm following.  I'm seeing this even with your change.
>
> Without filters:
>
>   $ ./perf report -s dso --stdio -q
>       98.41%  perf
>        1.11%  [kernel.kallsyms]
>        0.41%  ld-linux-x86-64.so.2
>        0.05%  libLLVM-16.so.1
>        0.03%  libc.so.6
>
>
> With filter:
>
>   $ ./perf report -s dso -d '[kernel.kallsyms],libc.so.6' --stdio -q
>        1.11%  [kernel.kallsyms]
>        0.03%  libc.so.6
>
> You said you want to have them combined together, right?
> But I think the current behavior makes more sense.


If you add a field to both sort and filter, then this change does not
affect anything (filtered fields already participate in
sorting/merging). It affects things when the filter field is not in
sort.

Consider the following queries:
"What symbols consume time in this subset of binaries (but not in the rest)?"
Naively, one would try:
perf report --sort=symbol --comm=cc1,ld
And this deceptively works and shows something, but as far as I
understand these are random numbers now.
With this change you can actually do this (you will see things like
malloc/free in both of these binaries, or if one profiles e.g. Go
programs, then there will be lots of common symbols from
runtime/stdlin).

Another example: profile for this particular subset of threads/cpus
(but not for the rest).

And in particular for:
https://lore.kernel.org/linux-perf-users/CACT4Y+an1LSY15f9MS_vnbaaeeqMf+k4-Dqqfu-zwcUAHFNk=w@xxxxxxxxxxxxxx/T/#t
I want to enable: --parallelism=1-8 filter.
Currently you will either see random garbage numbers, or if you add
'parallelism' to sort order, then you will see each symbol/comm
duplicated 8 times for each separate value of parallelism (which is
not useful). But currently you can't see symbol/comm for these 8
parallelism levels combined, but not for the rest.

All-in-all, this looks like a change that defines behavior that's
currently undefined in a useful and intuitive way, without changing
any of the currently defined behaviors.











> Thanks,
> Namhyung
>
> >
> > Signed-off-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
> > Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
> > Cc: Ian Rogers <irogers@xxxxxxxxxx>
> > Cc: linux-perf-users@xxxxxxxxxxxxxxx
> > Cc: linux-kernel@xxxxxxxxxxxxxxx
> > ---
> >  tools/perf/util/hist.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > index 8e4e844425370..b70170d854a0c 100644
> > --- a/tools/perf/util/hist.c
> > +++ b/tools/perf/util/hist.c
> > @@ -1303,9 +1303,18 @@ hist_entry__cmp_impl(struct perf_hpp_list *hpp_list, struct hist_entry *left,
> >       typedef int64_t (*fn_t)(struct perf_hpp_fmt *, struct hist_entry *, struct hist_entry *);
> >       struct hists *hists = left->hists;
> >       struct perf_hpp_fmt *fmt;
> > -     int64_t cmp = 0;
> > +     int64_t cmp;
> >       fn_t fn;
> >
> > +     /*
> > +      * Never collapse filtered and non-filtered entries.
> > +      * Note this is not the same as having an extra (invisible) fmt
> > +      * that corresponds to the filtered status.
> > +      */
> > +     cmp = (int64_t)!!left->filtered - (int64_t)!!right->filtered;
> > +     if (cmp)
> > +             return cmp;
> > +
> >       perf_hpp_list__for_each_sort_list(hpp_list, fmt) {
> >               if (ignore_dynamic && perf_hpp__is_dynamic_entry(fmt) &&
> >                   !perf_hpp__defined_dynamic_entry(fmt, hists))
> > --
> > 2.47.1.613.gc27f4b7a9f-goog
> >