[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160120152548.GS27085@kernel.org>
Date: Wed, 20 Jan 2016 12:25:48 -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 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.
Ah, I should have the hierarchy patches processed today, hopefully
posted to Ingo, thanks for splitting that patch as I asked, appreciated.
- Arnaldo
Powered by blists - more mailing lists