Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'

[Namhyung Kim]

On Thu, Oct 22, 2015 at 5:46 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/