[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160120152900.GT27085@kernel.org>
Date: Wed, 20 Jan 2016 12:29:00 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Jiri Olsa <jolsa@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
David Ahern <dsahern@...il.com>,
Stephane Eranian <eranian@...gle.com>,
Andi Kleen <andi@...stfloor.org>,
Wang Nan <wangnan0@...wei.com>,
Don Zickus <dzickus@...hat.com>,
Pekka Enberg <penberg@...nel.org>,
Moinuddin Quadri <moin18@...il.com>
Subject: Re: [RFC/PATCHSET 00/17] perf tools: Add support for hierachy view
(v2)
Em Wed, Jan 20, 2016 at 12:25:48PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 21, 2016 at 12:01:36AM +0900, Namhyung Kim escreveu:
> > On Wed, Jan 20, 2016 at 10:32:04AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Jan 20, 2016 at 09:34:51AM +0900, Namhyung Kim escreveu:
> > > > On Tue, Jan 19, 2016 at 05:59:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > > One thing I just noticed was that right after I ran:
>
> > > $ perf report --hie
>
> > > The tool suggests that I use the brand new '--hierarchy' option :-)
>
> > > How hard would it be to provide a way to disable some of the suggestions
> > > when what is randomly suggested is already what the user is doing?
>
> > We could add callbacks for each tip to check it.
>
> Right, I quickly thought about it and there are some issues, perhaps, in
> addition to the existing "unconditional" tips, we could introduce some
> way to register conditional tips, something like:
>
> tip__add_cond("For hierarchical output, try: perf report --hierarchy",
> &symbol_conf, symbol_conf__is_hierarchy_on);
>
> bool symbol_conf__is_hierarchy_on(const void *parm)
> {
> const struct symbol_conf *conf = parm;
> return conf->report_hierarchy;
> }
>
> But then this needs to run after we parse options, so it has to be added
> to both builtin-top.c and builtin-report.c and any other tool that needs
> to have whatever state evaluated after options are parsed, for state
> changed via option parsing.
>
> Yeah, in this specific case we wouldn't need to pass a parameter, as
> symbol_conf is global, but just to make the mechanism more general.
>
> Sometimes you'll need to pass say, &report, to have access to state for
> 'struct report' to look at report.max_stack and check if the user set
> --max-stack, etc.
Also say the user used some option, say '--call-graph dwarf', a tip
could notice that and state that one can control the amount of stack to
copy, or tell about some recent improvement about that specific option,
say a speedup, a fix, whatever.
- Arnaldo
Powered by blists - more mailing lists