[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1387377469.1717.12.camel@leonhard>
Date: Wed, 18 Dec 2013 23:37:49 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Ingo Molnar <mingo@...nel.org>
Cc: Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>,
Namhyung Kim <namhyung.kim@....com>,
LKML <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Arun Sharma <asharma@...com>, Jiri Olsa <jolsa@...hat.com>,
Rodrigo Campos <rodrigo@...g.com.ar>
Subject: Re: [RFC/PATCHSET 00/18] perf report: Add support to accumulate
hist periods (v3)
2013-12-18 (수), 10:46 +0100, Ingo Molnar:
> * Namhyung Kim <namhyung@...nel.org> wrote:
>
> > I changed the option as a separate --cumulate and added a new
> > "Total" column (and renamed the default "Overhead" column into
> > "Self"). The output will be sorted by total (cumulative) overhead
> > for now. The reason I changed to the --cumulate is that I still
> > think it's much different from other --callchain options and I plan
> > to add support for showing (remaining) callchains to cumulative
> > entries too. The --callchain option will take care of it even with
> > --cumulate option.
>
> So I still think this is a fantastic feature, and while this variant
> of the user interface is an improvement over the previous version, we
> are not there yet ;-)
Right. But I want to finish the core part of this patchset first. And
then I will work on the UI part since it'll be a quite large work by
itself, I guess.
>
> My main complaint that any variation of 'cumulative' or 'cumulate' is
> a tongue-twister to users. I certainly won't be able to remember it
> and will have to call up the manpage every time I use it - which will
> be very annoying. I'd probably not use the feature much.
>
> So lets approach this from the casual user's angle. Casual users don't
> really remember twisted names for command line options, they remember
> the big picture, big concepts, and they remember bits of the output:
>
> > When the -g cumulative option is given, it'll be shown like this:
> >
> > $ perf report --cumulate --stdio
> >
> > # Self Total 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 [.] _dl_sysdep_start
>
> So the natural way to get this would something like:
>
> perf report --total
>
> Or, if '--total' does not feel good, maybe we should change 'Total' to
> 'Siblings' or 'Children', and propagate that naming through the UI:
Childrend looks better to me.
>
> $ perf report --children --stdio
>
> # Self Children 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 [.] _dl_sysdep_start
>
> Which shows the sum of overhead of all child functions as well, not
> just ourselves.
>
> Anything but 'cumulative'. That word, beyond being a strange, hard to
> remember Latin word, also does not tell the user (or the developer)
> anything about _what_ is being accumulated. It could cover anything.
>
> I also think this option should be enabled by default - lets see how
> much people complain about that.
>
> Okay?
Okay. I'll make it default in the next spin.
Thanks,
Namhyung
--
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