* [Xenomai] filter ipipe tracing
@ 2014-01-14 12:35 David
2014-01-14 12:47 ` Gilles Chanteperdrix
0 siblings, 1 reply; 4+ messages in thread
From: David @ 2014-01-14 12:35 UTC (permalink / raw)
To: xenomai
Dear,
I'm actually tracing my Xenomai drivers/syscalls thanks to the ipipe trace
facility. Actually, every "ipipe/xenomai/rtdm drivers" procedures are
traced. I give a try with 5000 points, I'm able to trace about 5ms of
execution. This is already a huge help for some problems but (a) it is too
short for my new needs. The performance impact of tracing appears big
(about x2 on performance ?), (b) it makes my application instable (100% of
CPU usage).
(a) Is it possible to trace about 1-10s of execution ? (any hint ?).
(b) Could we reduce performance impact for tracing ? I used FTRACE in the
past, it was possible to filter the events or procedure names traced but I
don't know how to proceed with ipipe tracing.
Regards.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai] filter ipipe tracing
2014-01-14 12:35 [Xenomai] filter ipipe tracing David
@ 2014-01-14 12:47 ` Gilles Chanteperdrix
2014-01-14 17:30 ` David
0 siblings, 1 reply; 4+ messages in thread
From: Gilles Chanteperdrix @ 2014-01-14 12:47 UTC (permalink / raw)
To: David; +Cc: xenomai
On 01/14/2014 01:35 PM, David wrote:
> Dear,
>
> I'm actually tracing my Xenomai drivers/syscalls thanks to the ipipe trace
> facility. Actually, every "ipipe/xenomai/rtdm drivers" procedures are
> traced. I give a try with 5000 points, I'm able to trace about 5ms of
> execution. This is already a huge help for some problems but (a) it is too
> short for my new needs. The performance impact of tracing appears big
> (about x2 on performance ?), (b) it makes my application instable (100% of
> CPU usage).
>
> (a) Is it possible to trace about 1-10s of execution ? (any hint ?).
> (b) Could we reduce performance impact for tracing ? I used FTRACE in the
> past, it was possible to filter the events or procedure names traced but I
> don't know how to proceed with ipipe tracing.
If you are only interested in the events you generate, then you can
disable tracing of function entries and exit, and generate the events
you are interested in with ipipe_trace_special.
--
Gilles.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai] filter ipipe tracing
2014-01-14 12:47 ` Gilles Chanteperdrix
@ 2014-01-14 17:30 ` David
2014-01-14 18:04 ` Jan Kiszka
0 siblings, 1 reply; 4+ messages in thread
From: David @ 2014-01-14 17:30 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
OK thanks, it helps to reduce by two factor (div 2) the number of trace per
milliseconds ; more importantly is CPU usage lowered from 100% down to 50%.
On a trace of 100000 points, i reached 250ms. 25% of these tracepoints are
__ipipe_syscall_root+xxx that does not mean anything to me, but all
syscalls, scheduling decisions and interrupts are visible.
The resulting trace contains tracepoints on the current CPU that activates
the trace freeze. Is there a way to activate the simultaneous trace capture
on two+ cores ?
I see trace_mark(...info...) in the Xenomai code. I don't think this info
is displayed in ipipe trace, am I wrong ?
Regards.
2014/1/14 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> On 01/14/2014 01:35 PM, David wrote:
>
>> Dear,
>>
>> I'm actually tracing my Xenomai drivers/syscalls thanks to the ipipe trace
>> facility. Actually, every "ipipe/xenomai/rtdm drivers" procedures are
>> traced. I give a try with 5000 points, I'm able to trace about 5ms of
>> execution. This is already a huge help for some problems but (a) it is too
>> short for my new needs. The performance impact of tracing appears big
>> (about x2 on performance ?), (b) it makes my application instable (100% of
>> CPU usage).
>>
>> (a) Is it possible to trace about 1-10s of execution ? (any hint ?).
>> (b) Could we reduce performance impact for tracing ? I used FTRACE in the
>> past, it was possible to filter the events or procedure names traced but I
>> don't know how to proceed with ipipe tracing.
>>
>
> If you are only interested in the events you generate, then you can
> disable tracing of function entries and exit, and generate the events you
> are interested in with ipipe_trace_special.
>
>
> --
> Gilles.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai] filter ipipe tracing
2014-01-14 17:30 ` David
@ 2014-01-14 18:04 ` Jan Kiszka
0 siblings, 0 replies; 4+ messages in thread
From: Jan Kiszka @ 2014-01-14 18:04 UTC (permalink / raw)
To: David, Gilles Chanteperdrix; +Cc: xenomai
On 2014-01-14 18:30, David wrote:
> OK thanks, it helps to reduce by two factor (div 2) the number of trace per
> milliseconds ; more importantly is CPU usage lowered from 100% down to 50%.
> On a trace of 100000 points, i reached 250ms. 25% of these tracepoints are
> __ipipe_syscall_root+xxx that does not mean anything to me, but all
> syscalls, scheduling decisions and interrupts are visible.
>
> The resulting trace contains tracepoints on the current CPU that activates
> the trace freeze. Is there a way to activate the simultaneous trace capture
> on two+ cores ?
>
> I see trace_mark(...info...) in the Xenomai code. I don't think this info
> is displayed in ipipe trace, am I wrong ?
No, trace_mark are dead remainders of LTTng support. I'm slowly
converting them to ftrace tracepoints that you can then retrieve and
visualize with standard tools. It's an x86-64-only endeavor so far,
artifacts can be found in [1] for Xenomai 2 (on maintenance now). For
Xenomai 3, I didn't push anything yet.
Jan
[1] http://git.xenomai.org/xenomai-jki.git/log/?h=queues/ftrace
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-14 18:04 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-14 12:35 [Xenomai] filter ipipe tracing David
2014-01-14 12:47 ` Gilles Chanteperdrix
2014-01-14 17:30 ` David
2014-01-14 18:04 ` Jan Kiszka
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.