[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131105074650.GA2855@gmail.com>
Date: Tue, 5 Nov 2013 08:46:50 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Pekka Enberg <penberg@...nel.org>,
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>,
Stephane Eranian <eranian@...gle.com>,
Jiri Olsa <jolsa@...hat.com>,
Rodrigo Campos <rodrigo@...g.com.ar>,
Arun Sharma <asharma@...com>
Subject: Re: [RFC/PATCHSET 00/14] perf report: Add support to accumulate hist
periods (v2)
* Namhyung Kim <namhyung@...nel.org> wrote:
> Hi Ingo,
>
> On Fri, 1 Nov 2013 10:27:59 +0100, Ingo Molnar wrote:
> > * Namhyung Kim <namhyung@...nel.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
--
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