Message-ID: <20151103004647.GE21609@kernel.org>
Date:	Mon, 2 Nov 2015 21:46:47 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Brendan Gregg <brendan.d.gregg@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Kan Liang <kan.liang@...el.com>
Subject: Re: [RFC/PATCH 0/4] perf report: Support folded callchain output (v2)

Em Tue, Nov 03, 2015 at 08:46:06AM +0900, Namhyung Kim escreveu:
> On Mon, Nov 02, 2015 at 08:04:36PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Nov 03, 2015 at 07:49:27AM +0900, Namhyung Kim escreveu:
> > > On Mon, Nov 02, 2015 at 07:28:42PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Tue, Nov 03, 2015 at 07:12:04AM +0900, Namhyung Kim escreveu:
> > > > > On Mon, Nov 02, 2015 at 06:30:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > > Em Mon, Nov 02, 2015 at 12:37:28PM -0800, Brendan Gregg escreveu:
> > > > > > > On Mon, Nov 2, 2015 at 4:57 AM, Namhyung Kim <namhyung@...nel.org> wrote:
> > > > > > > > This is what Brendan requested on the perf-users mailing list [1] to
> > > > > > > > support FlameGraphs [2] more efficiently.  This patchset adds a few
> > > > > > > > more callchain options to adjust the output for it.
> > > > 
> > > > > > > > At first, 'folded' output mode was added.  The folded output puts all
> > > > > > > > calchain nodes in a line separated by semicolons, a space and the
> > > > > > > > value.  Now it only supports --stdio as other UI provides some way of
> > > > > > > > folding/expanding callchains dynamically.
> > > > 
> > > > > > > > The value is now can be one of 'percent', 'period', or 'count'.  The
> > > > > > > > percent is current default output and the period is the raw number of
> > > > > > > > sample periods.  The count is the number of samples for each callchain.
> > > > 
> > > > > > > > Here's an example:
> > > > 
> > > > > > > >   $ perf report --no-children --show-nr-samples --stdio -g folded,count
> > > > > > > >   ...
> > > > > > > >     39.93%     80  swapper  [kernel.vmlinux]  [k] intel_idel
> > > > > > > >   intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;start_secondary 57
> > > > > > > >   intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;... 23

> > > > > > > So for the folded output I don't need the summary line (the row of
> > > > > > > columns printed by hist_entry__snprintf()), and don't need anything
> > > > > > > except folded stacks and the counts. If working with the existing
> > > > > > > stdio interface is making it harder than it needs to be, might it be

> > > > > > I don't think it so, just add some flag asking for that
> > > > > > hist_entry__snprintf() to be supressed, ideas for a long option name?

> > > > > > Having it as Namhyung did may have value for some people as a more
> > > > > > compact way to show the callchains together with the hist_entry line.

> > > > > Yeah, I'd keep the hist entry line unless it's too hard to
> > > > > parse/filter.  IMHO it's just a way to show callchains, so no need to

> > > > What I suggested was to have something like:

> > > >   $ perf report --no-children --no-hists --stdio -g folded,count
> > > >                               ^^^^^^^^^^
> > > >                               ^^^^^^^^^^
> > > >   ...
> > > >   intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;start_secondary 57
> > > >   intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;... 23
> > > > 
> > > > I.e. the first entry in the callchain is 'intel_idle', just like in what
> > > > Brendan called the 'summary line', i.e. reduntant when what he wants its
> > > > just all the callchains and how many times they were sampled.

> > > Yep, I know.  But isn't 'perf report' all for seeing hist lines? :)

> > Well, so far, yes, but he is presenting a usecase where what we want to
> > see is just callchains, and we can achieve that rather easily, no?
 
> But it's also easy to filter from the script side.

Why not go all the way and provide just what the script wants?
 
> > > I'm not insisting it strongly, but it's a bit strange for me if perf
> > > report doesn't show any hist lines..
> > 
> > If that is of no use in this use case, why not?
> 
> Well, I think FlameGraphs is a rather unusual case and folded output
> seems useful to other use cases too.

Sure thing, I agreed with that, its just one flag to tell if the
hist_entry__snprintf should be used or not.

> > > > > have separate output mode..
> > > >  
> > > > > Brendan, I guess you still need to know other info like cpu or pid, no?
> > > > 
> > > > Possibly, but just with the callchains he has enough info for the basic
> > > > flame graph, no?
> > > >  
> > > > > And I feel like it'd be better to put the count before the callchains
> > > > > for consistency like below.  Is it OK to you?
> > > > 
> > > > Consistency with what?
> > > 
> > > Oh, I meant consistency with other callchain output style like graph,
> > > fractal or flat - They all show the numbers before callchains.  And I
> > > think it's easier to read for human. :)
> > 
> > Well, As I said, isn't the main object here the callchain? :-)
> > 
> > And Brendan's request is for a something to be consumed by scripts, i.e.
> > something like we have for perf stat:
> > 
> > For humans:
> > 
> > [root@...icio ~]# perf stat -e cycles -I 1000 -a
> > #           time             counts unit events
> >      1.000304391          1,820,038      cycles                   
> >      2.000490191      1,005,477,007      cycles                   
> >      3.000657813          1,717,007      cycles                   
> > ^C     3.917890293          2,804,034      cycles                   
> > 
> > For machines/scripts:
> > 
> > [root@...icio ~]# perf stat -x, -e cycles -I 1000 -a
> >      1.000291954,1923360,,cycles,3998167210,100.00
> >      2.000477154,1005608105,,cycles,3998475482,100.00
> >      3.000612612,1345483,,cycles,3998332391,100.00
> >      4.000744469,1005046913,,cycles,3998258199,100.00
> > ^C     4.331684347,1551327,,cycles,3463190970,100.00
> > 
> > [root@...icio ~]#
 
> Yes, I thought about it too.  Maybe -t/--field-separator option can be
> used to separate folded callchains too.

What I meant here was: for humans, we don't want a field separator, and
we want headers, we want alignment, etc, while for scripts, its better
something easily parseable and with a record per line, no alignment is
needed, etc.
 
> > > > The main thing here is the callchain, all the other stuff are things
> > > > related to it, so showing it first makes sense to me.
> > > > 
> > > > Having some way to list the desired info to have for each callchain may
> > > > be interesting, and if he could do it like:
> > > > 
> > > >    -g folded,count,cpu,other,fields
> > > > 
> > > > then he would know how to parse the per-callchain info at the end of
> > > > each line, right?
> > > 
> > > Hmm.. looks like that it ends up having redundant info.  I don't think
> > 
> > What is redundant, and with with what?
> 
> When it's used with normal perf report cases, those other info in
> callchain lines are redundant to hist lines.  Also if a hist entry has

Sure, but if the user doesn't want to see the output of
hist_entry__snprintf()... :-)

> many callchains, each callchain lines will have same info in other fields.

Sure, but that would be what the script expects to consume, i.e. one
line per callchain.

> > > it's generally useful to other 'perf report' stuffs.  Wouldn't it be
> > > better just adding minimal support and let the external tool parse the
> > > output?
> > 
> > Oh well, perhaps we could have a 'perf callchain' tool that would be
> > centered on callchains and would provided one line per callchain, which
> > would have:
> > 
> > callchain;seprarated;colons series,of,desired,fields,for,this,callchain
> > 
> > Which would reuse heavily the 'perf report' / 'perf top' code for
> > histograms, no?
 
> I guess the callchain code is pretty isolated or can be isolated
> easily though.
 
> > I still think that this is a 'perf report' thing, but one that is
> > centered in callchains, and that is to be consumed by scripts, not
> > humans.
 
> Agreed.
 
> I'm just looking for a way to support it with minimal change. :)

Hey, me too. A --no-hists flag looks like a quickie, no need to isolate
callchain code, or anything like that, just one long option switch and
we get what we need.

- Arnaldo
--
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