From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Dmitry Antipov <dmitry.antipov@linaro.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org,
patches@linaro.org
Subject: Re: [PATCH] perf sched replay: fix event lookup
Date: Tue, 12 Jun 2012 15:01:26 +0900 [thread overview]
Message-ID: <8739616pc9.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <20120611140852.GB2202@infradead.org> (Arnaldo Carvalho de Melo's message of "Mon, 11 Jun 2012 11:08:52 -0300")
Hi,
On Mon, 11 Jun 2012 11:08:52 -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 11, 2012 at 02:46:02PM +0900, Namhyung Kim escreveu:
>> On Sat, 9 Jun 2012 13:05:58 +0400, Dmitry Antipov wrote:
>> > Use new function trace_find_event_by_name to lookup events before
>> > looking through /sys files. This helps 'perf sched replay' to map
>> > event names to IDs correctly when processing perf.data recorded
>> > on another machine.
>>
>> Basically the same approach with the previous reply, please put this
>> into trace_event__id(). And minor nits below..
>
> Well, trace_event__id() is private to evlist and evlist so far is a
> local thing, i.e. it doesn't know anything about perf.data files.
>
Really? I see that perf_session__open make up an evlist for the session
and a tracepoint event in the evlist should look up the perf.data
first. As this patch addressed, perf sched replay dealt with the
session->evlist already. Am I missing something?
> So I think we should have a per perf.data (perf_session) method that
> knows that it shouldn't look _at all_ to /sys, but just at what came in
> the perf.data file.
>
Fair enough. The method should be a simple wrapper to libtraceevent APIs
like this patch.
> As well when we want something that is on the running machine, even if
> we're dealing somehow with a perf.data file, we shouldn't use what is in
> it.
>
That's the current behavior of the trace_event__id(). Do you want to
make it public?
Thanks,
Namhyung
next prev parent reply other threads:[~2012-06-12 6:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-09 9:05 [PATCH] perf sched replay: fix event lookup Dmitry Antipov
2012-06-11 5:46 ` Namhyung Kim
2012-06-11 14:08 ` Arnaldo Carvalho de Melo
2012-06-12 6:01 ` Namhyung Kim [this message]
2012-06-12 17:11 ` Arnaldo Carvalho de Melo
2012-06-25 23:20 ` Arnaldo Carvalho de Melo
2012-06-27 9:18 ` Dmitry Antipov
2012-06-27 14:21 ` Arnaldo Carvalho de Melo
2012-06-29 16:17 ` [tip:perf/core] perf tools: Stop using a global trace events description list tip-bot for Arnaldo Carvalho de Melo
2012-06-25 18:02 ` [PATCH] perf sched replay: fix event lookup Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8739616pc9.fsf@sejong.aot.lge.com \
--to=namhyung@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=dmitry.antipov@linaro.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patches@linaro.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.