lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Aug 2015 12:39:37 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	"Liang, Kan" <kan.liang@...el.com>
Cc:	Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
	Andi Kleen <ak@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC V9 2/3] perf,tools: per-event callgraph support

Em Mon, Aug 10, 2015 at 12:56:04PM +0000, Liang, Kan escreveu:
> > Em Fri, Aug 07, 2015 at 12:38:43PM -0300, Arnaldo Carvalho de Melo escreveu:
> > [root@zoo ~]# perf report --header-only
> > # cmdline :
> > /home/acme/bin/perf record -e {cpu/cpu-cycles,call-
> > graph=fp,time,period=10000/pp,cpu/instructions,call-
> > graph=no,time=0,period=20000/p} -a
<SNIP>

> > I get:

> > Samples: 2K of event 'cpu/instructions,call-
> > graph=no,time=0,period=20000/p', Event count (approx.): 46956518
> >   Children      Self  Command          Shared Object Symbol                  ◆
> > -   67.56%     0.00%  qemu-system-x86  [unknown]     [.]
> > 0xad5e258d4c544155  ▒
> >      0xad5e258d4c544155                                                      ▒
> > -   67.56%     0.00%  qemu-system-x86  libc-2.20.so  [.] __libc_start_main   ▒
> >      __libc_start_main                                                       ▒
> >      0xad5e258d4c544155                                                      ▒

> > This is in the 'perf report' TUI, why, for an event with 'callgraph=no', we get
> > callchains? How come?
 
> That's the design.
> For sampling multiple events, it may not be needed to collect callgraphs for
> all of them. Because the sample sites are usually nearby. It's enough to collect
> the callgraphs on a reference event. For other events, it can still show callgraphs
> according to the callgraphs on a reference event.

So, "call-graph=no" doesn't mean you don't want callchains for a
particular events _if_ there is another event in the group for which
callchains is available.

But if "call-graph=no" for all events, then, yes, "no" means really
"no". :-)

I think we should use "call-graph=ref" to mean that no callchains should
be requested to the kernel infrastructure for that particular event, but
that when doing the report, use callchains available in some other event
(perhaps would be good to specify which one), while "call-graph=no"
really means "no", i.e. no callchains asked from the kernel for this
event, and _no_ callchains to appear on report.

If "ref" is used and no callchains are available anywhere, that is a bug
as well, i.e. I asked for callchains up to a event to be used, by
getting that info from another event, but no event has callchains:
error.

- 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ