From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755433AbbCFEmT (ORCPT ); Thu, 5 Mar 2015 23:42:19 -0500 Received: from lgeamrelo01.lge.com ([156.147.1.125]:42115 "EHLO lgeamrelo01.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755364AbbCFEmS (ORCPT ); Thu, 5 Mar 2015 23:42:18 -0500 X-Original-SENDERIP: 10.177.220.203 X-Original-MAILFROM: namhyung@kernel.org Date: Fri, 6 Mar 2015 13:38:06 +0900 From: Namhyung Kim To: Frederic Weisbecker , Arnaldo Carvalho de Melo Cc: Ingo Molnar , Peter Zijlstra , Jiri Olsa , LKML , Adrian Hunter , Stephane Eranian , Andi Kleen , David Ahern Subject: Re: [PATCH 12/38] perf tools: Introduce thread__comm_time() helpers Message-ID: <20150306043806.GC7872@sejong> References: <1425352070-1115-1-git-send-email-namhyung@kernel.org> <1425352070-1115-13-git-send-email-namhyung@kernel.org> <20150303162837.GA26830@lerouge> <20150304000255.GF27046@danjae> <20150305160854.GF5074@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150305160854.GF5074@lerouge> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Frederic and Arnaldo, On Thu, Mar 05, 2015 at 05:08:56PM +0100, Frederic Weisbecker wrote: > On Wed, Mar 04, 2015 at 09:02:55AM +0900, Namhyung Kim wrote: > > Hi Frederic, > > > > On Tue, Mar 03, 2015 at 05:28:40PM +0100, Frederic Weisbecker wrote: > > > On Tue, Mar 03, 2015 at 12:07:24PM +0900, Namhyung Kim wrote: > > > > When data file indexing is enabled, it processes all task, comm and mmap > > > > events first and then goes to the sample events. So all it sees is the > > > > last comm of a thread although it has information at the time of sample. > > > > > > > > Sort thread's comm by time so that it can find appropriate comm at the > > > > sample time. The thread__comm_time() will mostly work even if > > > > PERF_SAMPLE_TIME bit is off since in that case, sample->time will be > > > > -1 so it'll take the last comm anyway. > > > > > > > > Cc: Frederic Weisbecker > > > > Signed-off-by: Namhyung Kim > > > > --- > > > > tools/perf/util/thread.c | 33 ++++++++++++++++++++++++++++++++- > > > > tools/perf/util/thread.h | 2 ++ > > > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c > > > > index 9ebc8b1f9be5..ad96725105c2 100644 > > > > --- a/tools/perf/util/thread.c > > > > +++ b/tools/perf/util/thread.c > > > > @@ -103,6 +103,21 @@ struct comm *thread__exec_comm(const struct thread *thread) > > > > return last; > > > > } > > > > > > > > +struct comm *thread__comm_time(const struct thread *thread, u64 timestamp) > > > > > > Usually thread__comm_foo() would suggest that we return the "foo" from a thread comm. > > > For example thread__comm_len() returns the len of the last thread comm. > > > thread__comm_str() returns the string of the last thread comm. > > > > Ah, okay. > > I mean, that's just an impression, others may have a different one :o) Right. Although I agree with your idea of function naming, I'm not sure it's worth changing every function call site for this - and for similar machine__find(new)_thread()_time. Arnaldo, What do you think? Thanks, Namhyung