[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM9d7cibrsM-Nv-QnFzxKsZ43+sUAm=vE-Caqy3usKjzQ2phug@mail.gmail.com>
Date: Tue, 17 Nov 2020 01:40:45 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
Stephane Eranian <eranian@...gle.com>,
Ian Rogers <irogers@...gle.com>
Subject: Re: [PATCH] perf stat: Take cgroups into account for shadow stats
Hi Andi,
On Sun, Nov 15, 2020 at 10:05 PM Andi Kleen <ak@...ux.intel.com> wrote:
>
> > @@ -57,6 +59,9 @@ static int saved_value_cmp(struct rb_node *rb_node, const void *entry)
> > if (a->ctx != b->ctx)
> > return a->ctx - b->ctx;
> >
> > + if (a->cgrp != b->cgrp)
> > + return (char *)a->cgrp < (char *)b->cgrp ? -1 : +1;
>
> This means the sort order will depend on heap randomization,
> which will make it harder to debug.
>
> Better use something stable like the inode number of the cgroup.
I don't think they are used for sorting. It's just to compare to find a
matching event value.
For heap randomization, we already used the same technique
for evsel and runtime_stat pointers. I can make it use cgroup id
but not sure it is really worth it.
>
> Do we have the same problem with other filters?
I'm not aware of it.
>
> The rest of the patch looks good to me.
Thanks for the review!
Namhyung
Powered by blists - more mailing lists