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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 03 Nov 2014 18:58:49 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Alexandre Montplaisir <alexmonthy@...populi.im>,
	Jiri Olsa <jolsa@...hat.com>
CC:	linux-kernel@...r.kernel.org,
	Dominique Toupin <dominique.toupin@...csson.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Jeremie Galarneau <jgalar@...icios.com>,
	David Ahern <dsahern@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: FW: [RFC 0/5] perf tools: Add perf data CTF conversion

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
--
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/