[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131218094622.GA19240@gmail.com>
Date: Wed, 18 Dec 2013 10:46:22 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Namhyung Kim <namhyung@...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)
* 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 ;-)
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:
$ 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?
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