Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate histperiods (v2)

From: Frederic Weisbecker
Date: Mon Nov 04 2013 - 08:34:31 EST


On Thu, Oct 31, 2013 at 09:09:32AM +0100, Ingo Molnar wrote:
>
>
> * Namhyung Kim <namhyung@xxxxxxxxxx> wrote:
>
> > When the -g cumulative option is given, it'll be shown like this:
> >
> > $ perf report -g cumulative --stdio
> >
> > # Overhead Overhead (Acc) Command Shared Object Symbol
> > # ........ .............. ....... ................. .......................
> > #
> > 0.00% 88.29% abc libc-2.17.so [.] __libc_start_main
> > 0.00% 88.29% abc abc [.] main
> > 0.00% 88.29% abc abc [.] c
> > 0.00% 88.29% abc abc [.] b
> > 88.29% 88.29% abc abc [.] a
> > 0.00% 11.61% abc ld-2.17.so [k] _dl_sysdep_start
> > 0.00% 9.43% abc ld-2.17.so [.] dl_main
> > 9.43% 9.43% abc ld-2.17.so [.] _dl_relocate_object
> > 2.27% 2.27% abc [kernel.kallsyms] [k] page_fault
> > 0.00% 2.18% abc ld-2.17.so [k] _dl_start_user
> > 0.00% 0.10% abc ld-2.17.so [.] _start
> >
> > As you can see __libc_start_main -> main -> c -> b -> a callchain
> > show up in the output.
>
> This looks really useful!
>
> A couple of details:
>
> 1)
>
> This is pretty close to SysProf output, right? So why not use the
> well-known SysProf naming and call the first column 'self' and the
> second column 'total'? I think those names are pretty intuitive and
> it would help people who come from SysProf over to perf.
>
> 2)
>
> Is it possible to configure the default 'report -g' style, so that
> people who'd like to use it all the time don't have to type '-g
> cumulative' all the time?
>
> 3)
>
> I'd even argue that we enable this reporting feature by default, if
> a data file includes call-chain data: the first column will still
> show the well-known percentage that perf report produces today, the
> second column will be a new feature in essence.
>
> The only open question would be, by which column should we sort:
> 'sysprof style' sorts by 'total', 'perf style' sorts by 'self'.
> Agreed?

Defaulting that behaviour may make sense but we can expect some visible overhead
out of it though. Adding one hist per callchain entry has probably some
measurable impact.

How about we wait to see that option mature upstream a bit first then we can
decide about making it the default once we have measured and maybe optimized
the resulting overhead?

Thanks.
--
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/