From: Ingo Molnar <mingo@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Pekka Enberg <penberg@kernel.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
Namhyung Kim <namhyung.kim@lge.com>,
LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Stephane Eranian <eranian@google.com>,
Jiri Olsa <jolsa@redhat.com>,
Rodrigo Campos <rodrigo@sdfg.com.ar>,
Arun Sharma <asharma@fb.com>
Subject: Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2)
Date: Tue, 5 Nov 2013 08:46:50 +0100 [thread overview]
Message-ID: <20131105074650.GA2855@gmail.com> (raw)
In-Reply-To: <87bo1zz4mu.fsf@sejong.aot.lge.com>
* Namhyung Kim <namhyung@kernel.org> wrote:
> Hi Ingo,
>
> On Fri, 1 Nov 2013 10:27:59 +0100, Ingo Molnar wrote:
> > * Namhyung Kim <namhyung@kernel.org> wrote:
> >
> >> >> > 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?
> >> >>
> >> >> Hmm.. maybe I can add support for the 'report.call-graph' config option.
> >> >
> >> > If we display your new 'total' field by default then it's not as
> >> > pressing to me :)
> >>
> >> Do you mean -g cumulative without 'self' column?
> >
> > So, if by default we display both 'self' and 'total' and sort by
> > 'total', then I'm personally a happy camper: while it's a change of
> > the default perf report output, it's also a step forward.
> >
> > But some people might complain about it once this hits v3.13 (or
> > v3.14) and might want to hide individual columns and have different
> > sorting preferences.
> >
> > So out of defensive caution you might want to provide toggles for
> > such things, maybe even generalize it a bit to allow arbitrary
> > hiding/display of individual colums in perf report.
> >
> > That would probably also make it easier to do minimal tweaks to the
> > upstream reporting defaults.
>
> Okay, so what would the interface look like?
>
> I think it'd better to separate the option and pass column and
> (optional) sort key argument.
>
> --cumulative both,total (default)
> --cumulative both,self
> --cumulative total
> --cumulative self (meaningless?)
>
> Maybe we need a config option and a single letter option for the default
> case like --call-graph and -g options do.
>
> What do you think?
So why restrict it to 'cumulative'? Why not have a generic --fields/-F,
with a good default. The ordering of the fields determines sorting
behavior.
The default would be something like:
-F total,self,process,dso,name
Whether 'cumulative' data is calculated is not a function of any direct
option, but simply a function of whether the 'total' field is in the -F
list of columns displayed or not.
With that scheme we could also do things like this to get old-style
sorting:
-F self,process,dso,name
Or a really frugal 'readprofile'-style output:
-F self,name
if one is only interested in percentages and raw function names.
Wrt. sorting order, by default the first column in the list of columns
would be the primary (and only) sort key.
(The -F field setup list could also be specified in the .perfconfig.)
With this method we could do away with all this geometrical explosion of
somewhat inconsistent formatting and sorting options...
If there's demand then we could decouple sort keys from the display order,
by slightly augmenting the field format:
-F total,self:2,process:0,dso:1,name
This would sort by 'process' field as the primary key, 'dso' the secondary
key and 'self' as the tertiary key.
And we could also keep the -s/--sort option:
-s process,dso,self
So the above -F line would be equivalent to:
-F total,self,process,dso,name -s process,dso,self
What do you think?
Thanks,
Ingo
next prev parent reply other threads:[~2013-11-05 7:46 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 6:56 [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2) Namhyung Kim
2013-10-31 6:56 ` [PATCH 01/14] perf tools: Consolidate __hists__add_*entry() Namhyung Kim
2013-11-01 11:56 ` Jiri Olsa
2013-11-06 5:43 ` [tip:perf/core] perf hists: " tip-bot for Namhyung Kim
2013-10-31 6:56 ` [PATCH 02/14] perf tools: Introduce struct add_entry_iter Namhyung Kim
2013-11-01 12:07 ` Jiri Olsa
2013-11-05 7:09 ` Namhyung Kim
2013-11-01 12:09 ` Jiri Olsa
2013-11-05 7:16 ` Namhyung Kim
2013-10-31 6:56 ` [PATCH 03/14] perf hists: Convert hist entry functions to use struct he_stat Namhyung Kim
2013-11-04 23:45 ` Arnaldo Carvalho de Melo
2013-11-05 7:17 ` Namhyung Kim
2013-10-31 6:56 ` [PATCH 04/14] perf hists: Add support for accumulated stat of hist entry Namhyung Kim
2013-10-31 6:56 ` [PATCH 05/14] perf hists: Check if accumulated when adding a " Namhyung Kim
2013-10-31 6:56 ` [PATCH 06/14] perf hists: Accumulate hist entry stat based on the callchain Namhyung Kim
2013-10-31 6:56 ` [PATCH 07/14] perf tools: Update cpumode for each cumulative entry Namhyung Kim
2013-11-01 12:55 ` Jiri Olsa
2013-11-05 7:41 ` Namhyung Kim
2013-10-31 6:56 ` [PATCH 08/14] perf report: Cache cumulative callchains Namhyung Kim
2013-10-31 11:13 ` Rodrigo Campos
2013-11-01 7:07 ` Namhyung Kim
2013-11-01 14:24 ` Rodrigo Campos
2013-11-01 15:16 ` Rodrigo Campos
2013-11-01 12:29 ` Jiri Olsa
2013-11-01 12:57 ` Jiri Olsa
2013-10-31 6:56 ` [PATCH 09/14] perf hists: Sort hist entries by accumulated period Namhyung Kim
2013-10-31 6:56 ` [PATCH 10/14] perf ui/hist: Add support to accumulated hist stat Namhyung Kim
2013-10-31 6:56 ` [PATCH 11/14] perf ui/browser: " Namhyung Kim
2013-10-31 6:56 ` [PATCH 12/14] perf ui/gtk: " Namhyung Kim
2013-10-31 6:56 ` [PATCH 13/14] perf tools: Apply percent-limit to cumulative percentage Namhyung Kim
2013-10-31 6:56 ` [PATCH 14/14] perf report: Add -g cumulative option Namhyung Kim
2013-11-01 13:17 ` Jiri Olsa
2013-11-05 7:44 ` Namhyung Kim
2013-10-31 8:09 ` [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist periods (v2) Ingo Molnar
2013-11-01 6:48 ` Namhyung Kim
2013-11-01 7:55 ` Ingo Molnar
2013-11-01 9:18 ` Pekka Enberg
2013-11-01 9:22 ` Namhyung Kim
2013-11-01 9:27 ` Ingo Molnar
2013-11-05 7:31 ` Namhyung Kim
2013-11-05 7:46 ` Ingo Molnar [this message]
2013-11-05 9:05 ` Namhyung Kim
2013-11-05 11:58 ` Ingo Molnar
2013-11-06 7:56 ` Namhyung Kim
2013-11-06 8:30 ` Ingo Molnar
2013-11-06 9:17 ` Namhyung Kim
2013-11-06 11:47 ` Ingo Molnar
2013-11-06 12:14 ` Frederic Weisbecker
2013-11-11 12:13 ` Ingo Molnar
2013-11-11 13:08 ` Frederic Weisbecker
2013-11-11 13:56 ` Ingo Molnar
2013-11-11 15:45 ` Frederic Weisbecker
2013-11-06 15:33 ` David Ahern
2013-11-11 12:19 ` Ingo Molnar
2013-11-11 14:44 ` David Ahern
2013-11-12 12:08 ` Pekka Enberg
2013-11-06 16:09 ` Peter Zijlstra
2013-11-11 12:17 ` Ingo Molnar
2013-11-06 12:10 ` Frederic Weisbecker
2013-11-11 12:12 ` Ingo Molnar
2013-11-11 13:01 ` Frederic Weisbecker
2013-11-04 13:27 ` Frederic Weisbecker
2013-11-04 13:23 ` Frederic Weisbecker
2013-11-04 13:34 ` Frederic Weisbecker
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=20131105074650.GA2855@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=asharma@fb.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=namhyung.kim@lge.com \
--cc=namhyung@kernel.org \
--cc=paulus@samba.org \
--cc=penberg@kernel.org \
--cc=rodrigo@sdfg.com.ar \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.