From: Akihiro Nagai <akihiro.nagai.hw@hitachi.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
2nddept-manager@sdl.hitachi.co.jp,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'
Date: Fri, 24 Dec 2010 19:04:23 +0900 [thread overview]
Message-ID: <4D147027.7000802@hitachi.com> (raw)
In-Reply-To: <20101221183131.GO1750@nowhere>
(2010/12/22 3:31), Frederic Weisbecker wrote:
[...]
>> +static int process_sample_event(event_t *event __unused,
>> + struct sample_data *sample, struct perf_session *session __unused)
>> +{
>> + /* sample->ip is 'from address', sample->addr is 'to address' */
>> + printf(FMT_ADDR " => " FMT_ADDR "\n", sample->ip, sample->addr);
>
> It seems this unconditionally prints out the event, but a sample
> event can be about anything. If you recorded only branches it's fine,
> but if there were other events this will mess up.
Exactly.
I'll add a check code of PERF_SAMPLE_ID there.
And, I found the problem that perf cannot handle the data including
multiple event types. I executed following command to make perf.data
includes two event types: hardware and software event.
# perf record -e branches:u -c 1 -d -e raw_syscalls:sys_enter ls
(... ls outputs)
[ perf record: Woken up 18 times to write data ]
[ perf record: Captured and wrote 4.468 MB perf.data (~195216 samples) ]
# perf bts trace
Fatal: non matching sample_type
It results in error. Other perf subcommands also failed on this recorded data.
For example, perf annotate, perf script, perf report.
In the future, I would like to analyze BTS log and other type events
at the same time.
>
> Well, when you launch the tool you can iterate into the session->header.attr
> and check if there is something else than a branch perf event. And then emit
> a warning if so.
>
> That doesn't solve the problem but the user will know there is one.
>
> Actually the best would be to select PERF_SAMPLE_ID in the sample_type
> on record and also PERF_FORMAT_ID in the read_format.
>
> Then you can find the PERF_SAMPLE_ID that matches your event. If we
> record that in the perf headers we can retrieve which events id are the
> branch ones.
Agreed.
>
> But well, that's a secondary problem for now.
Thank you for your advise!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
------------------------------------
Akihiro Nagai
Email: akihiro.nagai.hw@hitachi.com
next prev parent reply other threads:[~2010-12-24 10:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-21 9:05 [PATCH -tip v2 0/6] perf: Introduce bts sub commands Akihiro Nagai
2010-12-21 9:05 ` [PATCH -tip v2 1/6] perf: Introduce perf sub command 'bts record' Akihiro Nagai
2010-12-21 9:05 ` [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace' Akihiro Nagai
2010-12-21 18:31 ` Frederic Weisbecker
2010-12-21 18:40 ` Peter Zijlstra
2010-12-21 18:45 ` Frederic Weisbecker
2010-12-21 18:52 ` Peter Zijlstra
2010-12-21 19:02 ` Frederic Weisbecker
2010-12-21 19:56 ` Peter Zijlstra
2010-12-21 21:33 ` Frederic Weisbecker
2010-12-21 21:41 ` Peter Zijlstra
2010-12-24 10:04 ` Akihiro Nagai [this message]
2010-12-21 9:05 ` [PATCH -tip v2 3/6] perf bts trace: print pid and command Akihiro Nagai
2010-12-21 9:06 ` [PATCH -tip v2 4/6] perf bts trace: print file path of the executed elf Akihiro Nagai
2010-12-21 9:06 ` [PATCH -tip v2 5/6] perf bts trace: print function+offset Akihiro Nagai
2010-12-21 9:06 ` [PATCH -tip v2 6/6] perf bts trace: add print all option Akihiro Nagai
2010-12-21 17:36 ` [PATCH -tip v2 0/6] perf: Introduce bts sub commands Frederic Weisbecker
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=4D147027.7000802@hitachi.com \
--to=akihiro.nagai.hw@hitachi.com \
--cc=2nddept-manager@sdl.hitachi.co.jp \
--cc=acme@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=peterz@infradead.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.