lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ