From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754438AbbCFMsL (ORCPT ); Fri, 6 Mar 2015 07:48:11 -0500 Received: from mail.kernel.org ([198.145.29.136]:54109 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751053AbbCFMsH (ORCPT ); Fri, 6 Mar 2015 07:48:07 -0500 Date: Fri, 6 Mar 2015 09:48:05 -0300 From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Frederic Weisbecker , 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: <20150306124805.GZ5187@kernel.org> 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> <20150306043806.GC7872@sejong> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150306043806.GC7872@sejong> X-Url: http://acmel.wordpress.com 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 Em Fri, Mar 06, 2015 at 01:38:06PM +0900, Namhyung Kim escreveu: > 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: > > > 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. > > > > > +++ 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. So you need to find a thread using a new search key, namely (pid, tid, time), is that right? I.e. you process all the meta events so that you can have the lifetime events for the whole session, right? If that is the case, then I think we should keep the existing functions as is, for tools not yet converted to this new way of processing samples, be it just because there was no time yet to do it or because we may find that it is not adequate for some tools, and introduce the new API, that takes the time as part of the key, so, in addition to: machine__find_thread machine__findnew_thread namely: machine__find_thread_by_time machine__findnew_thread_by_time But thread__comm_time() for me is to get the time of most recent comm for that thread. I.e. I agree with Frédéric, if what you want is to _find_ the comm for a specific key, i.e. time, then I think it should be: thread__find_comm_by_time(thread, tstamp) Ah, how do you manage the thread rbtree? First a search by pid/tid and then another by time? Or put it all together and then machine__find_thread becomes just a: struct thread *machine__find_thread(machine, pid, tid) { return machine__find_thread_by_time(machine, pid, tid, -1); } And it returns the most recent thread for that pid/tid? I.e. machine__remove_thread() becomes a noop for such use cases and we never delete a struct thread instance? - Arnaldo