Re: [PATCH] perf c2c: Fix sorting.
From: Andres Freund
Date: Thu Jan 09 2020 - 12:00:47 EST
Hi,
On 2020-01-09 09:48:22 +0100, Jiri Olsa wrote:
> On Wed, Jan 08, 2020 at 08:30:30PM -0800, Andres Freund wrote:
> > Commit 722ddfde366f ("perf tools: Fix time sorting") changed -
> > correctly so - hist_entry__sort to return int64. Unfortunately several
> > of the builtin-c2c.c comparison routines only happened to work due the
> > cast caused by the wrong return type.
> >
> > This causes meaningless ordering of both the cacheline list, and the
> > cacheline details page. E.g a simple
> > perf c2c record -a sleep 3
> > perf c2c report
> > will result in cacheline table like
> > =================================================
> > Shared Data Cache Line Table
> > =================================================
> > #
> > # ----------- Cacheline ---------- Total Tot ----- LLC Load Hitm ----- ---- Store Reference ---- --- Load Dram ---- LLC Total ----- Core Load Hit ----- -- LLC Load Hit --
> > # Index Address Node PA cnt records Hitm Total Lcl Rmt Total L1Hit L1Miss Lcl Rmt Ld Miss Loads FB L1 L2 Llc Rmt
> > # ..... .................. .... ...... ....... ....... ....... ....... ....... ....... ....... ....... ........ ........ ....... ....... ....... ....... ....... ........ ........
> > #
> > 0 0x7f0d27ffba00 N/A 0 52 0.12% 13 6 7 12 12 0 0 7 14 40 4 16 0 0 0
> > 1 0x7f0d27ff61c0 N/A 0 6353 14.04% 1475 801 674 779 779 0 0 718 1392 5574 1299 1967 0 115 0
> > 2 0x7f0d26d3ec80 N/A 0 71 0.15% 16 4 12 13 13 0 0 12 24 58 1 20 0 9 0
> > 3 0x7f0d26d3ec00 N/A 0 98 0.22% 23 17 6 19 19 0 0 6 12 79 0 40 0 10 0
> > i.e. with the list not being ordered by Total Hitm.
> >
> > Fixes: 722ddfde366f ("perf tools: Fix time sorting")
> > Signed-off-by: Andres Freund <andres@xxxxxxxxxxx>
> > Cc: Jiri Olsa <jolsa@xxxxxxxxxx>
> > Cc: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> > Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> > Cc: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>
> > Cc: Michael Petlan <mpetlan@xxxxxxxxxx>
> > Cc: Namhyung Kim <namhyung@xxxxxxxxxx>
> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx # v3.16+
> > ---
> > tools/perf/builtin-c2c.c | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> > index e69f44941aad..f2e9d2b1b913 100644
> > --- a/tools/perf/builtin-c2c.c
> > +++ b/tools/perf/builtin-c2c.c
> > @@ -595,8 +595,8 @@ tot_hitm_cmp(struct perf_hpp_fmt *fmt __maybe_unused,
> > {
> > struct c2c_hist_entry *c2c_left;
> > struct c2c_hist_entry *c2c_right;
> > - unsigned int tot_hitm_left;
> > - unsigned int tot_hitm_right;
> > + uint64_t tot_hitm_left;
> > + uint64_t tot_hitm_right;
>
> that change looks right, but I can't see how that could
> happened because of change in Fixes: tag
>
> was the return statement of this function:
>
> return tot_hitm_left - tot_hitm_right;
>
> considered to be 'unsigned int' and then converted to int64_t,
> which would treat negative 'unsigned int' as big positive 'int64_t'?
Correct. So e.g. when comparing 1 and 2 tot_hitm, we'd get (int64_t)
UINT_MAX as a result, which is obviously wrong. However, due to
hist_entry__sort() returning int at the time, this was masked, as the
int64_t was cast to int. Thereby again yielding a negative number for
the comparisons of hist_entry__sort()'s result. After
hist_entry__sort() was fixed however, there never could be negative
return values (but 0's are possible) of hist_entry__sort() for c2c.
I briefly looked for places outside of c2c for similar issues in
hist_entry comparison routines, but didn't find any.
Greetings,
Andres Freund