Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932671AbbHJS52 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 10 Aug 2015 14:57:28 -0400
Received: from mga09.intel.com ([134.134.136.24]:38151 "EHLO mga09.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932576AbbHJS50 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 10 Aug 2015 14:57:26 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.15,647,1432623600"; 
   d="scan'208";a="622833776"
From: "Liang, Kan" <kan.liang@intel.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
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
Thread-Topic: [PATCH RFC V9 2/3] perf,tools: per-event callgraph support
Thread-Index: AQHQ0L00G1F8ocgTRE2LrVXdCAzqOZ4Ar+cvgASDs2D//6pVgIAAqbkQ
Date: Mon, 10 Aug 2015 18:57:20 +0000
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F077018DF6B7@SHSMSX103.ccr.corp.intel.com>
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>
In-Reply-To: <20150810153937.GC20967@kernel.org>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t7AIvW7S005820
Content-Length: 2638
Lines: 58



> <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
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?