Messages in this thread | | | Date | Thu, 5 Nov 2015 00:34:57 +0900 | From | Namhyung Kim <> | Subject | Re: [PATCHSET 0/4] perf report: Support folded callchain output (v4) |
| |
Hi Arnaldo and Brendan,
On Wed, Nov 04, 2015 at 11:51:31AM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Nov 03, 2015 at 10:02:32PM -0800, Brendan Gregg escreveu: > > On Tue, Nov 3, 2015 at 5:54 PM, Namhyung Kim <namhyung@kernel.org> wrote: > > > Ah, makes sense. So it'd look like > > > > $ perf report --stdio -g folded,count,info -F none -s comm > > > $ perf report --stdio -g folded,count,info -F none -s pid > > > > The output would be > > > > 809 swapper-0 cpu_bringup_and_idle;cpu_startup_entry;default_idle_call;arch_cpu_idle;default_idle;xen_hypercall_sched_op > > > Thanks, looks almost right: a couple of minor changes: > > > 1. If perf already has the precedent of "PID:comm", instead of my > > "comm-PID", then maybe it should use "PID:comm" for perf consistency. > > Doesn't make much difference to me.
Right. Actually I'd like to write it that way.. ;-)
> > 2. The second space, delimiting "PID:comm" (or comm) and the stack... > > I'm nervous about using space as a delimiter any more than once, since > > it can also appear in comm (eg, "java main") and frames (eg, > > "JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, > > Thread*)" -- that's direct from "perf script"!). I'd consider making > > it a semicolon:
Fair enough.
> > > 809 swapper-0;cpu_bringup_and_idle;cpu_startup_entry;... > > > So the output is "value key", and key is a semicolon delimited stack > > with an optional comm or PID:comm frame at the start. > > Agreed, but then, we can have some sort of default and also be able to, > using -F, specify what are the fields we want, and in which order, and I > liked your suggestion of being able to specify "-F none" and that mean > no hist line to be produced. > > Likewise, the way that each callchain line should be formatted should be > programmable via the command line, via the -g option, no? Then script > writers could use it in a way that doesn't requires further processing, > as Brendan showed.
Right. So '-s <key1>[,<key2>,...] -g info' can control which info is displayed along with the callchains.
$ perf report -s comm,dso -g folded,count,info -F none 809 swapper;[kernel.vmlinux];cpu_bringup_and_idle;cpu_startup_entry;...
Note that the info part (swapper;[kernel.vmlinux]) is also separated by a semicolon. But I think it's ok since it's controlled by command line, so script can know how many entries will be.
> > But yeah, the value is the semicolon delimited stack all the way to the > comm/PID:comm if there are more than one or if the user asks it to be > there via a -g keyword, all the other counts/info are just relative to > that, CSV or whatever other delimiter the user asks it to, and space is > not an option, as we know it can appear in the middle of a COMM:
Yes, I think that we should use a given separator (using -t option) instead of hard-coded semicolon. Although it'd be rare, it seems possible to use semicolons in the comm name too.
Thanks, Namhyung
> > [root@zoo ~]# perf report -s comm | grep '[a-zA-Z] [a-zA-Z]' > # To display the perf.data header info, please use > # --header/--header-only options. > # Total Lost Samples: 0 > # Samples: 164K of event 'cycles:pp' > # Event count (approx.): 34422160859 > 0.11% DOM Worker > 0.10% JS Helper > 0.01% Qt bearer threa > 0.00% Socket Thread > 0.00% dconf worker > 0.00% JS Watchdog > [root@zoo ~]# > > - Arnaldo
| |