From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753813AbdJSWtP (ORCPT ); Thu, 19 Oct 2017 18:49:15 -0400 Received: from mga04.intel.com ([192.55.52.120]:20766 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbdJSWtN (ORCPT ); Thu, 19 Oct 2017 18:49:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,403,1503385200"; d="scan'208";a="164749376" Subject: Re: [PATCH v4 2/6] perf record: Get the first sample time and last sample time To: Arnaldo Carvalho de Melo Cc: jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org, ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com References: <1507040558-20344-1-git-send-email-yao.jin@linux.intel.com> <1507040558-20344-3-git-send-email-yao.jin@linux.intel.com> <20171019202127.GB30002@kernel.org> <20171019202549.GC30002@kernel.org> From: "Jin, Yao" Message-ID: Date: Fri, 20 Oct 2017 06:49:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171019202549.GC30002@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/20/2017 4:25 AM, Arnaldo Carvalho de Melo wrote: > Em Thu, Oct 19, 2017 at 05:21:27PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Tue, Oct 03, 2017 at 10:22:34PM +0800, Jin Yao escreveu: >>> In perf record, it's walked on all samples yet. So it's very easy to get >> >> You're saying that perf record walks all samples always? That only >> happens when we generate the build-id table, right? And people disable >> that to speed up the process, knowing that some limitations will come >> from that, for doing analysis right after running it is mostly OK to >> disable the build-id processing. > > So either you add a new option that processes all events without doing > build-id processing (and all the locking, struct thread, map, etc > processing it entails) and just looks at the sample->time, and when > build id processing is enabled, just do as you're doing in this patch, > then, at perf report --time you should look to see if those start/end > times were filled in and if not tell that to the user, i.e. that > either --record-time-boundaries (or a better name :-) ) has to be used, > or, that build-id process, with a short explanation that > --record-time-boundaries is a bit cheaper. > > - Arnaldo > Hi Arnaldo, Thanks so much for reminding me that the walking only happens when build-id processing is enabled. Yes, the step is same as what you said so there will be an issue when the build-id processing is disabled. According to your suggestion, I will provide a new option "--record-time-boundaries" in perf record. If user disables the build-id processing, the perf record will ask user to set the "--record-time-boundaries". If user enables the build-id processing, the perf record will not ask user to set the "--record-time-boundaries". Also in perf report, if it doesn't see start/end time filled in the perf file header, it will show some information to let user know he should set "--record-time-boundaries" or enable the build-id processing in perf record. I will provide v5 patch series, maybe some days later. Thanks Jin Yao