Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932656AbbHJTjv (ORCPT <rfc822;w@1wt.eu>);
	Mon, 10 Aug 2015 15:39:51 -0400
Received: from mail.kernel.org ([198.145.29.136]:40527 "EHLO mail.kernel.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932431AbbHJTju (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 10 Aug 2015 15:39:50 -0400
Date: Mon, 10 Aug 2015 16:39:42 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
        Andi Kleen <ak@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC V9 2/3] perf,tools: per-event callgraph support
Message-ID: <20150810193942.GF2521@kernel.org>
References: <1438890294-33409-1-git-send-email-kan.liang@intel.com>
 <1438890294-33409-2-git-send-email-kan.liang@intel.com>
 <20150807153843.GD3325@kernel.org>
 <20150807154938.GE3325@kernel.org>
 <37D7C6CF3E00A74B8858931C1DB2F077018DE420@SHSMSX103.ccr.corp.intel.com>
 <20150810153937.GC20967@kernel.org>
 <37D7C6CF3E00A74B8858931C1DB2F077018DF6B7@SHSMSX103.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F077018DF6B7@SHSMSX103.ccr.corp.intel.com>
X-Url: http://acmel.wordpress.com
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4401
Lines: 102

Em Mon, Aug 10, 2015 at 06:57:20PM +0000, Liang, Kan escreveu:
> > <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.

I don't have much of a problem with that, but using "ref" to make the
intention, i.e. use reference callchains, documented, clear, makes sense to me.

I.e. when you ask for two events, one with callchains and the other without it
doesn't necessarily means we want callchains appearing on the ones we have not
enabled them.

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

Ok, if the user explicitely asked for "--show-callchain-ref", then
he/she will not get confused seeing callchains for an event with
"call-graph=no".

Ah, probably --show-ref-call-graph should be better, to keep it consistent with
all the other options dealing with call-graph stuff.

> If not, no callchain information is printed for "call-graph=no" event.
> The default is no print.

Agreed, I think this almost completely reduces the possible source of
confusion.

> Is it OK?

Ok.

One possible improvement to your proposal: When showing callchains in
reference mode, make that extra explicit by adding some marker on the
side of the event name.

I.e. right now we will see callchains, when this is with another event with
callchains:

  Samples: 24  of event 'cpu/instructions,call-graph=no,time=0,period=20000/p', Event count (approx.): 480000
  Overhead  Command  Shared Object     Symbol
    12.50%  usleep   libc-2.20.so      [.] _dl_addr

My suggestion is to have something like:

  Samples: 24  of event 'cpu/instructions,call-graph=no,time=0,period=20000/p', ref cg, Event count (approx.): 480000
  Overhead  Command  Shared Object     Symbol
    12.50%  usleep   libc-2.20.so      [.] _dl_addr

See that ", ref cg"?

But would be just to remove the confusion of seeing, on the same screen,
"call-graph=no" when one _sees_ call graphs.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/