[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAM9d7cioyALcz8uBbk-vQ42fL3VxrCh5LBbHis0UikbvNyQF0Q@mail.gmail.com>
Date: Thu, 22 Oct 2015 21:36:37 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>,
"Wangnan (F)" <wangnan0@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Borislav Petkov <bp@...e.de>,
Chandler Carruth <chandlerc@...il.com>,
David Ahern <dsahern@...il.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Jiri Olsa <jolsa@...hat.com>,
Stephane Eranian <eranian@...gle.com>,
pi3orama <pi3orama@....com>
Subject: Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'
On Thu, Oct 22, 2015 at 5:46 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Arnaldo Carvalho de Melo <acme@...hat.com> wrote:
>
>> > 5) --no-children
>> >
>> > I agree that 'perf top -g --no-children' looks more intuitive than 'perf top -g'.
>>
>> So, what do you propose, to switch back the default to --no-children, for both
>> tools, top and report? Now that I am getting used to it... ;-)
>
> Heh ;-) So I'm only thinking out loud, trying to find the most intuitive initial
> screen to display. Expert users can configure their output any which way they want
> it to be, I'm not worried about them.
:)
>
> It's casual and in particular first-time users we should be worried about most -
> if they try the '-g' option in record, what will they first see in 'perf report'
> output?
>
> I think the best output method would be to include only the 'highest level' parent
> symbols, with all children summed up under the parent's entry. Isn't the new
> 'graph,0.5,caller' default very close to that?
Hmm.. not sure I'm following well. what do you mean by 'highest level
parent'? Do you want single depth callchains for each entry?
>
> But what confuses me about the output is the same that confused Wangnan's users:
>
> "This is my story: after switching to new version of perf, in a period of time
> there are plenty of perf users in my company be confused by the first column of
> 'perf report' because the sum of the percentage listed there is much higher than
> 100%. They find me because they think this is a bug in perf which breaks their
> routinely profiling work."
>
> So this is suboptimal.
>
> The first column is 'Children', which should show the sum of all child overhead -
> but if a child overhead was already included under a parent, it should never show
> up under another parent's entry. I.e. the first column should only contain the
> highest level entries, no sub-entries.
Again, I don't understand. Could you elaborate it more probably with
example below?
>
> But what we do currently is:
>
> Children Self Command Shared Object Symbol
> - 70.41% 0.00% cc1 cc1 [.] toplev_main
> - toplev_main
> + __libc_start_main
> - 70.38% 0.00% cc1 libc-2.20.so [.] __libc_start_main
> + __libc_start_main
>
> i.e. even though '__libc_start_main' is a child of 'toplev_main', it's still
> included on the 'overview' page.
Strange. AFAIK 'toplev_main' is a child of '__libc_start_main'. Are
you using 'caller' ordering?
Also I think 'main' should be shown between 'toplev_main' and
'__libc_start_main' but maybe it's a different issue.
Thanks,
Namhyung
>
> Is there an output method that can do what I suggest above?
>
> ( Having both 'children' and 'self' columns in itself is intuitive IMHO: it shows
> that an entry that is shown does not directly have overhead at that level, a
> child call of it has that overhead. )
>
> Thanks,
>
> Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists