linux-kernel - RE: [PATCH RFC V9 2/3] perf,tools: per-event callgraph support

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]

Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018DF6B7@SHSMSX103.ccr.corp.intel.com>
Date:	Mon, 10 Aug 2015 18:57:20 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
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



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

If we use " call-graph=ref", it means "ref" is a new callchain mode. But it's not.
I think the "ref" thing should only impact the perf report.
So we may introduce a new option "--show-callchain-ref" for that purpose.
If it applied, the available callchain information from other event will be
printed for "call-graph=no" event.
If not, no callchain information is printed for "call-graph=no" event.
The default is no print.
Is it OK?

Thanks,
Kan