Message-ID: <20150306124805.GZ5187@kernel.org>
Date:	Fri, 6 Mar 2015 09:48:05 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	David Ahern <dsahern@...il.com>
Subject: Re: [PATCH 12/38] perf tools: Introduce thread__comm_time() helpers

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists