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]

Message-ID: <53F4F38C.4080407@voxpopuli.im>
Date:	Wed, 20 Aug 2014 15:14:20 -0400
From:	Alexandre Montplaisir <alexmonthy@...populi.im>
To:	Jiri Olsa <jolsa@...hat.com>
CC:	linux-kernel@...r.kernel.org,
	Dominique Toupin <dominique.toupin@...csson.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	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 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.

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 tried to record/display lttng event perf:cpu:cycles, but got nothing
> displayed in eclipse. Looks like this data provides only summary count
> of the event for the workload?

Just to be sure I understand, you recorded an LTTng kernel trace, in 
which you enabled the "perf:cpu:cycles" context? Did this trace display 
anything in Babeltrace?
It should display the same in the Eclipse viewer, the value of the 
context will be visible in the "Contents" column in the the table (and 
in the Properties view), although for now we don't make any use of it.

 From what I understand, yes, the value of the different perf:* contexts 
represents the value of the perf counter at the moment the tracepoint 
was hit. So you cannot get perf data "in between" trace events when 
using this method.

Cheers,
Alexandre
--
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/