From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754006AbdJSUZx (ORCPT ); Thu, 19 Oct 2017 16:25:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:55360 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752742AbdJSUZw (ORCPT ); Thu, 19 Oct 2017 16:25:52 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 921B0218A6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=acme@kernel.org Date: Thu, 19 Oct 2017 17:25:49 -0300 From: Arnaldo Carvalho de Melo To: Jin Yao 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 Subject: Re: [PATCH v4 2/6] perf record: Get the first sample time and last sample time Message-ID: <20171019202549.GC30002@kernel.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171019202127.GB30002@kernel.org> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > - Arnaldo > > > the first/last samples and save the time to perf file header via the > > function write_sample_time(). > > > > In later, perf report/script will fetch the time from perf file header. > > > > Change log: > > ----------- > > v3: Remove the definitions of first_sample_time and last_sample_time > > from struct record and directly save them in perf_evlist. > > > > Signed-off-by: Jin Yao > > --- > > tools/perf/builtin-record.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c > > index 9b379f3..d5b78449 100644 > > --- a/tools/perf/builtin-record.c > > +++ b/tools/perf/builtin-record.c > > @@ -488,6 +488,11 @@ static int process_sample_event(struct perf_tool *tool, > > > > rec->samples++; > > > > + if (rec->evlist->first_sample_time == 0) > > + rec->evlist->first_sample_time = sample->time; > > + > > + rec->evlist->last_sample_time = sample->time; > > + > > return build_id__mark_dso_hit(tool, event, sample, evsel, machine); > > } > > > > -- > > 2.7.4