From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750933AbbLBFVd (ORCPT ); Wed, 2 Dec 2015 00:21:33 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:51179 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750814AbbLBFVb (ORCPT ); Wed, 2 Dec 2015 00:21:31 -0500 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: namhyung@kernel.org X-Original-SENDERIP: 165.244.98.204 X-Original-MAILFROM: namhyung@kernel.org X-Original-SENDERIP: 10.177.227.17 X-Original-MAILFROM: namhyung@kernel.org Date: Wed, 2 Dec 2015 14:20:53 +0900 From: Namhyung Kim To: Arnaldo Carvalho de Melo CC: Jiri Olsa , David Ahern , Ingo Molnar , Peter Zijlstra , LKML , Kan Liang , Frederic Weisbecker , Andi Kleen , Wang Nan Subject: Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address Message-ID: <20151202052053.GB12758@sejong> References: <1448521700-32062-1-git-send-email-namhyung@kernel.org> <1448521700-32062-2-git-send-email-namhyung@kernel.org> <565705D1.705@gmail.com> <20151126150018.GA21474@danjae.kornet> <565729C1.4030802@gmail.com> <20151126155857.GB31756@krava.brq.redhat.com> <20151126161901.GD2945@kernel.org> MIME-Version: 1.0 In-Reply-To: <20151126161901.GD2945@kernel.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2015/12/02 14:20:52, Serialize by Router on LGEKRMHUB07/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2015/12/02 14:20:53, Serialize complete at 2015/12/02 14:20:53 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 26, 2015 at 01:19:01PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 26, 2015 at 04:58:57PM +0100, Jiri Olsa escreveu: > > On Thu, Nov 26, 2015 at 08:48:17AM -0700, David Ahern wrote: > > > On 11/26/15 8:00 AM, Namhyung Kim wrote: > > > >Hi David, > > > > > > > >On Thu, Nov 26, 2015 at 06:14:57AM -0700, David Ahern wrote: > > > >>On 11/26/15 12:08 AM, Namhyung Kim wrote: > > > >>>@@ -528,11 +529,16 @@ int main(int argc, const char **argv) > > > >>> { > > > >>> const char *cmd; > > > >>> char sbuf[STRERR_BUFSIZE]; > > > >>>+ int min_addr; > > > >>> > > > >>> /* The page_size is placed in util object. */ > > > >>> page_size = sysconf(_SC_PAGE_SIZE); > > > >>> cacheline_size = sysconf(_SC_LEVEL1_DCACHE_LINESIZE); > > > >>> > > > >>>+ if (sysctl__read_int("vm/mmap_min_addr", &min_addr) < 0) > > Please put this in that symbol_conf kitchen sink :-) > > I'm unsure though if there would be a reason for having both the local > min_addr and the one at perf record time, i.e. from perf.data :-\ Otherwise, it can use different value and can treat valid addresses as invalid especially if the difference is huge. Btw, I think it should be kernel to cut off these invalid callchains in the first place, no? > > > > >>This assumes the record and analysis are done on the same system. > > > > > > > >Right. Maybe we can just use minimal size (or page size?) or save and > > > >pass it through somewhere in the feature bit? > > > > > > no preference, but it should work with cross arch analysis as well (e.g., > > > record on arm/ppc and analysis on x86) > > > > I think we should store it in perf.data in features, but seems > > like a waste to spend one bit just for this number. > > > > I remember commenting on new CPU related FEATURE data, that would contain > > cpu specific data in extensible form like TAG,VALUE,TAG,VALUE.. > > > > but I think the design changed or something, because I cannot find it in now ;-) > > > > maybe we could add something like that > > Right, isn't that one part of the perf/stat patchkit? I'll take a look. Jiri, could you give the link if you have it? Thanks, Namhyung