Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 08/20/2014 09:14 PM, Alexandre Montplaisir wrote:
> On 08/20/2014 05:28 AM, Jiri Olsa wrote:
>>
>> ok, easy enough ;-) so I'm guessing this governs the expected
>> CTF layout for event/stream headers/contexts, right?
> 
> Correct, if the domain is "kernel" we then assume that the rest of the
> trace contains the expected elements of a kernel trace.

So that is one thing that I had to add.

> Of course, one could craft a CTF trace to advertize itself as "kernel"
> or "ust", and not actually have the layout of that trace type, in which
> case it would fail parsing later on.
> 
>> Also judging from the trace display, you have hardcoded specific
>> displays/actions for specific events? That's all connected/specific
>> under trace type?
> 
> Yes the trace type is the main "provider" of functionality. I could go
> into more details, but we use Eclipse extension points to define which
> columns to put in the event table, which views are available, etc. for
> each supported trace type.
> 
>>> Once we have some views or analysis specific to perf CTF traces, we
>>> could
>>> definitely add a separate trace type for those too.
>> I guess tracepoints and breakpoints should display something like
>> the standard kernel trace. As for HW events it's usual to display
>> profile infomation as the perf report does:
>>   
>> https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record
> 
> Interesting, I haven't tried the perf CTF output yet, but I could see it
> using the Statistics view (which by default just prints the % of events,
> per event type) to print the results of the different "perf reports",
> calculated from the CTF events. Eventually with pie charts!

I did on the linux side:

|perf record \
| -e sched:sched_switch \
| -a

This gave me perf.data trace. No with the new extension I converted it
into CTF data stream (perf data convert -i perf.data --to-ctf ctf) and
imported it into eclipse as a new trace. By setting 'domain = "kernel"'
I managed to get it accepted as a kernel trace.

Additionally I had to:
- rename sched:sched_switch -> sched_switch (I dropped the other events)
- rename "perf_cpu" to "cpu_id" and move it within "packet context"
  (had a patch for that but we wanted to merge this later)
- I added "prev_tid" with the content of "prev_pid" and I added
  "next_tid" with the content of "next_pid". Now exclipse does not
  "freeze" after loading the first entry
- I prefixed every entry with _ (so "prev_tid" becomes "_prev_tid") and
  now it seems to be recognized by the tracing plugin.

puh. Now I have something in "cpu usage", "control flow" windows.
The cpu_id field change will be addressed soon on our side.
Now, the remaining things:
The "domain = kernel" thingy (or another identifier if desired) is
something we could add.
What do we do on the naming convention?

The converter takes basically the event names the way they come from
perf. That is why we have a "system" prefix.
For the member fields, we take all the specific ones as perf serves
them. The only exception is for the generic fields which get a "perf_"
prefix in order not to clash with the specific ones.
And there is this _ prefix in front of every data member.

Now that I identified the differences between the CTF from lttng and
perf, any suggestions / ideas how this could be solved?

> Cheers,
> Alexandre

Sebastian