[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5476A84B.6040500@voxpopuli.im>
Date: Wed, 26 Nov 2014 23:27:55 -0500
From: Alexandre Montplaisir <alexmonthy@...populi.im>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC: Jiri Olsa <jolsa@...hat.com>, 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>,
Trace Compass Developer Discussions
<tracecompass-dev@...ipse.org>, matthew.khouzam@...csson.com,
andreas@...utronix.de
Subject: Re: Support for Perf CTF traces now in master (was Re: FW: [RFC 0/5]
perf tools: Add perf data CTF conversion)
On 2014-11-26 12:37 PM, Sebastian Andrzej Siewior wrote:
> * Alexandre Montplaisir | 2014-11-12 17:14:45 [-0500]:
>
>> Just a quick note, this branch is now merged to master. So anyone who
>> pulls the code from the master branch at
>> git://git.eclipse.org/gitroot/tracecompass/org.eclipse.tracecompass.git
>> should be able to load perf-CTF traces in the viewer. The trace type
>> is now called "Common Trace Format -> Linux Kernel Trace" and should
>> support both LTTng kernel and perf traces in CTF format (although
>> auto-detection should work in most cases).
> Thank you for all the work.
> Let me try to reply to the emails at once here:
> - I added to the environment metadata the following (comparing to the
> last version):
> domain => kernel
> tracer_name => perf
>
> There is no tracer_major + minor. Instead I added
> version => perf's version
> On my system I have:
> release = "3.16.0-4-amd64";
> version = "3.18.rc3.g91405a";
>
> Because I run Debian's v3.16 and recorded the trace with perf from the
> kernel 3.18.rc3.
> There is no version of perf doing the convert of perf.data => ctf.
> Any objections, rename of the version member?
>
> - Mathieu decided that it makes no sense to add the kernel version to
> each event we trace. Instead each event should have its own version
> with a major/minor member. Once the event is changed the "ABI"
> version should be adjusted. I second this since it makes sense.
> Therefore there are no changes that were made to the converter.
>
> - Alexandre (you) noticed that there are syscall names in the events
> recorded via "sys_enter and sys_exit". This is true, but there is a
> hint. There is an event for instance:
>
> [03:37:07.579969498] (+?.?????????) raw_syscalls:sys_enter: { cpu_id = 2 }, { perf_ip = 0xFFFFFFFF81020EBC, perf_tid = 30004, perf_pid = 30004, perf_id = 382, perf_period = 1, common_type = 76, common_flags = 0, common_preempt_count = 0, common_pid = 30004, id = 16, args = [ [0] = 0xE, [1] = 0x2400, [2] = 0x0, [3] = 0x0, [4] = 0xA20F00, [5] = 0xA1FDA0 ] }
Oh ok, so this "id" field is really the system call ID then. Good to
know, thanks!
>
> By the end you notice id=16 and args. args are the Arguments passed
> to syscall and id is the syscall number. Together with machine =
> x86_64 you know which architecture you need to lookup the number 16.
> The numbers are from unistd.h (and may be different between architectures,
> even between i386 & x86_64). strace has for instance the following [0] table.
>
> { 3, TD, sys_read, "read" }, /* 0 */
> …
> { 3, TD, sys_ioctl, "ioctl" }, /* 16 */
> …
>
> So 16 is ioctl. strace has those tables for a bunch of architectures
> so it might be helpful to suck them in. I know no other way to ease
> things here.
Indeed. Well this information could be part of the trace metadata too,
but I guess that wouldn't be very practical.
We'll just need to add a way for each supported tracer to advertize how
it gets its system call names.
>
> [0] https://github.com/bnoordhuis/strace/blob/master/linux/x86_64/syscallent.h
>
> The same thing is true for softirq_entry events for instance. This event
> will give you you only vec=9 and you need to lookup that 9 => RCU. That
> one is easy however:
>
> const char * const softirq_to_name[NR_SOFTIRQS] = {
> "HI", "TIMER", "NET_TX", "NET_RX", "BLOCK", "BLOCK_IOPOLL",
> "TASKLET", "SCHED", "HRTIMER", "RCU"
> };
>
> this has been taken from kernel/softirq.c.
Oh, that's right, we never got around to getting/showing the actual
names of the soft IRQs. Thanks for reminding us. ;)
>> This was based on the most recent file format I was aware of, we will
>> update it accordingly if required.
>>
>> Testing welcome!
> I pushed the perf changes I mentioned to
>
> git://git.breakpoint.cc/bigeasy/linux.git ctf_convert_7
>
> It is now based on Arnaldo's perf/core. If everything goes well from
> the compass side and nobody complains here in any way, the next step
> would be to present the patches on the mailing list and compass as a
> user.
>
> I took you tree and added the patch below. I uploaded the following
> files to https://breakpoint.cc/perf-ctf/:
> - ctf-out6.tar.xz from perf6.data.xz
> shows nothing
Hmm, indeed it throws exceptions in the console when trying to validate
the trace. It seems to read a packet size in perf_stream_0 as a negative
value. Babeltrace handles it fine though, so we're probably reading it
wrong. We'll investigate.
Cheers,
Alexandre
>
> - ctf-out7.tar.xz from perf7.data.xz
> shows something
>
> The only obvious difference is the size of the CTF data. The size of out6
> is almost 300MiB and it contains 3,259,929 events. The out7 is has only
> 15MiB and contains 152,900 events.
>
>> Cheers,
>> Alexandre
> ✂
>
> From 7ffa619d918f2010046b391ae29063ffc5329468 Mon Sep 17 00:00:00 2001
> From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Date: Wed, 26 Nov 2014 18:04:53 +0100
> Subject: [PATCH] CTF: use tracer_name for perf-CTF traces
>
> domain will be set to kernel for both, perf and lttng traces. The
> tracer_name will be set to perf if the trace is generated by perf and
> otherwise lttng-modules if created by thet lttng tool.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
> .../tracecompass/lttng2/kernel/core/trace/LttngKernelTrace.java | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/org.eclipse.tracecompass.lttng2.kernel.core/src/org/eclipse/tracecompass/lttng2/kernel/core/trace/LttngKernelTrace.java b/org.eclipse.tracecompass.lttng2.kernel.core/src/org/eclipse/tracecompass/lttng2/kernel/core/trace/LttngKernelTrace.java
> index a58269f..03a09b9 100644
> --- a/org.eclipse.tracecompass.lttng2.kernel.core/src/org/eclipse/tracecompass/lttng2/kernel/core/trace/LttngKernelTrace.java
> +++ b/org.eclipse.tracecompass.lttng2.kernel.core/src/org/eclipse/tracecompass/lttng2/kernel/core/trace/LttngKernelTrace.java
> @@ -96,12 +96,11 @@ public class LttngKernelTrace extends CtfTmfTrace {
> * metadata
> */
> Map<String, String> traceEnv = this.getCTFTrace().getEnvironment();
> - String domain = traceEnv.get("domain"); //$NON-NLS-1$
> String tracerName = traceEnv.get("tracer_name"); //$NON-NLS-1$
> String tracerMajor = traceEnv.get("tracer_major"); //$NON-NLS-1$
> String tracerMinor = traceEnv.get("tracer_minor"); //$NON-NLS-1$
>
> - if ("\"kernel-perf\"".equals(domain)) { //$NON-NLS-1$
> + if ("\"perf\"".equals(tracerName)) { //$NON-NLS-1$
> fOriginTracer = OriginTracer.PERF;
>
> } else if ("\"lttng-modules\"".equals(tracerName) && //$NON-NLS-1$
> @@ -130,7 +129,7 @@ public class LttngKernelTrace extends CtfTmfTrace {
> CTFTrace temp = new CTFTrace(path);
> /* Make sure the domain is "kernel" in the trace's env vars */
> String dom = temp.getEnvironment().get("domain"); //$NON-NLS-1$
> - if (dom != null && dom.startsWith("\"kernel")) { //$NON-NLS-1$
> + if (dom != null && dom.equals("\"kernel\"")) { //$NON-NLS-1$
> return new TraceValidationStatus(CONFIDENCE, Activator.PLUGIN_ID);
> }
> return new Status(IStatus.ERROR, Activator.PLUGIN_ID, Messages.LttngKernelTrace_DomainError);
--
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/
Powered by blists - more mailing lists