lkml.org 
[lkml]   [2010]   [Dec]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -tip v2 2/6] perf bts: Introduce new sub command 'perf bts trace'
(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


\
 
 \ /
  Last update: 2010-12-24 11:07    [W:0.076 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site