From: Namhyung Kim <namhyung@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
"Wangnan (F)" <wangnan0@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Borislav Petkov <bp@suse.de>,
Chandler Carruth <chandlerc@gmail.com>,
David Ahern <dsahern@gmail.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Jiri Olsa <jolsa@redhat.com>,
Stephane Eranian <eranian@google.com>,
pi3orama <pi3orama@163.com>
Subject: Re: [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller'
Date: Thu, 22 Oct 2015 21:36:37 +0900 [thread overview]
Message-ID: <CAM9d7cioyALcz8uBbk-vQ42fL3VxrCh5LBbHis0UikbvNyQF0Q@mail.gmail.com> (raw)
In-Reply-To: <20151022084655.GA19913@gmail.com>
On Thu, Oct 22, 2015 at 5:46 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Arnaldo Carvalho de Melo <acme@redhat.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
next prev parent reply other threads:[~2015-10-22 12:36 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 21:03 [GIT PULL 00/16] perf/core improvements and fixes Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 01/16] tools lib api fs: No need to use PATH_MAX + 1 Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 02/16] perf evlist: Display DATA_SRC sample type bit Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 03/16] perf annotate: Fix sizeof_sym_hist overflow issue Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 04/16] perf tools: Export perf_event_attr__set_max_precise_ip() Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 05/16] perf tools: Introduce 'P' modifier to request max precision Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 06/16] perf tests: Add parsing test for 'P' modifier Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 07/16] perf tools: Add support for sorting on the iaddr Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 08/16] perf tools: Setup proper width for symbol_iaddr field Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 09/16] perf tools: Handle -h and -v options Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 10/16] perf tests: Add arch tests Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 11/16] perf tests: Move x86 tests into arch directory Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 12/16] perf tests: Add Intel CQM test Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 13/16] perf callchain: Switch default to 'graph,0.5,caller' Arnaldo Carvalho de Melo
2015-10-09 20:34 ` Brendan Gregg
2015-10-09 21:56 ` Arnaldo Carvalho de Melo
2015-10-09 22:10 ` Brendan Gregg
2015-10-09 22:25 ` Arnaldo Carvalho de Melo
2015-10-20 0:16 ` Brendan Gregg
2015-10-20 12:00 ` Arnaldo Carvalho de Melo
2015-10-20 12:19 ` Frederic Weisbecker
2015-10-20 13:06 ` Arnaldo Carvalho de Melo
2015-10-20 17:21 ` Frederic Weisbecker
2015-10-20 18:44 ` Arnaldo Carvalho de Melo
2015-10-21 1:21 ` Namhyung Kim
2015-10-21 13:24 ` Arnaldo Carvalho de Melo
2015-10-21 8:09 ` Namhyung Kim
2015-10-21 11:57 ` Wangnan (F)
2015-10-21 16:35 ` Frederic Weisbecker
[not found] ` <CAAwGriEtYeBytGt9x24=uUqSEy5oJ2HigfA2KXnKyrAioKrtNg@mail.gmail.com>
2015-10-21 16:27 ` Frederic Weisbecker
2015-10-21 18:28 ` Brendan Gregg
2015-10-21 19:23 ` Arnaldo Carvalho de Melo
2015-10-22 0:44 ` Brendan Gregg
2015-10-21 8:06 ` Ingo Molnar
2015-10-21 13:21 ` Arnaldo Carvalho de Melo
2015-10-21 19:18 ` Brendan Gregg
2015-10-10 7:09 ` Ingo Molnar
2015-10-10 7:34 ` Brendan Gregg
2015-10-10 9:07 ` Ingo Molnar
2015-10-12 15:27 ` Frederic Weisbecker
2015-10-13 4:26 ` Namhyung Kim
2015-10-19 23:50 ` Brendan Gregg
2015-10-21 7:29 ` Namhyung Kim
2015-10-20 13:23 ` Wangnan (F)
2015-10-20 13:38 ` Arnaldo Carvalho de Melo
2015-10-21 1:44 ` Namhyung Kim
2015-10-21 8:48 ` Ingo Molnar
2015-10-21 13:43 ` Arnaldo Carvalho de Melo
2015-10-21 13:46 ` Arnaldo Carvalho de Melo
2015-10-22 8:46 ` Ingo Molnar
2015-10-22 12:36 ` Namhyung Kim [this message]
2015-10-05 21:03 ` [PATCH 14/16] perf ui browser: Optional horizontal scrolling key binding Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 15/16] perf hists browser: Implement horizontal scrolling Arnaldo Carvalho de Melo
2015-10-05 21:03 ` [PATCH 16/16] perf tools: Fail properly in case pattern matching fails to find tracepoint Arnaldo Carvalho de Melo
2015-10-06 7:09 ` [GIT PULL 00/16] perf/core improvements and fixes Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAM9d7cioyALcz8uBbk-vQ42fL3VxrCh5LBbHis0UikbvNyQF0Q@mail.gmail.com \
--to=namhyung@kernel.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=bp@suse.de \
--cc=chandlerc@gmail.com \
--cc=dsahern@gmail.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=pi3orama@163.com \
--cc=wangnan0@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).