linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).