Re: [Xenomai] i-pipe tracer on in production kernels? (was Re: Altera Cyclone V)

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 01/11/2014 08:01 PM, Philippe Gerum wrote:
> On 01/11/2014 07:27 PM, Gilles Chanteperdrix wrote:
>> On 01/11/2014 07:20 PM, Philippe Gerum wrote:
>>> On 01/11/2014 11:22 AM, Michael Haberler wrote:
>>>> 
>>>> http://www.xenomai.org/index.php/I-pipe:Tracer describes the
>>>> trace API, which could be useful to track down issues
>>>> 
>>>> Q: does enabling the tracer incur significant overhead if
>>>> compiled in but unused, or is it reasonable to leave it on in a
>>>> production kernel?
>>>> 
>>>> if the former, we might have to build/make available a second
>>>> i-pipe tracer enabled kernel to track down issues 'in the
>>>> field'; if the latter, it'd be less build/distribution chores
>>>> 
>>> 
>>> The I-pipe tracer is based on the ftrace infrastructure, so
>>> tracepoints are left out when the tracer is disabled. If you can
>>> live with the minimal overhead ftrace adds, then leaving the
>>> I-pipe tracer code built in may be an option.
>> 
>> That is less true without DYNAMIC_FTRACE than with DYNAMIC_FTRACE.
>> 
>> 
> 
> This is about 10% overhead on low-end 52xx, 5-7% on am335x. I did not
> check on typical x86 < 2 Ghz yet, but this should be around 3-5%. It
> is just a matter of how much is too much.
> 
> Regarding DYNAMIC_FTRACE, we have had this out for too many moons
> (2.6.2x...), and we need to reconsider this (this looks somewhat like
> an old writing from an ancient book, nobody really remembers the
> meaning of - I wonder if I was not the guy who switched this off, out
> of some nightmare debugging session).

I believed it was me, but checking the logs, it seems to be due to this
commit:

https://git.xenomai.org/ipipe-gch.git/commit/kernel/trace/Kconfig?h=for-ipipe-2.6.29-arm&id=6e8b204b6ec92ca007ec099f2878c340f5b64b48

So, it seems it has been that way since the I-pipe tracer is based on
ftrace.

> 
> Anyway, enabling it on am335x looks ok at first sight, and I suspect
> that the usual problem of synchronizing better and harder against the
> code patching loop is gone.

I have tried on OMAP3 on my side, and I agree it seems to work. The code
patching is done within an ipipe_critical added by the I-pipe patch.

-- 
                                                                Gilles.