Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

[Steven Rostedt]

On Wed, 21 May 2008, Remy Bohmer wrote:

> Now I understood your hint in some other mail, and I am going to take
> a look at ftrace for ARM. Just for the fun of it...
> I hope it is not too intrusive for these ARM cores (old implementation
> was...), these Atmel cores are just not that fast as the common X86's.

If you feel brave, take a crack at the DYNAMIC_FTRACE. It's been done for
x86 (both 32 and 64 bit), PPC (also both 32 and 64 bit) as well as
Sparc64.

The dynamic ftrace is self modifying code, that will start off having
mcount simply call a nop. Then later it will change that to call a
"record_ip" function. A daemon is kicked off to change all the IPs that
are called into NOPs. When tracing is enabled, all the NOPs are converted
into calls to the trace function.

Dynamic ftrace also adds a "set_filter_function" in the /debugfs/tracing
directory that lets you echo in function names, and only those functions
will enable have tracing enabled.

All this helps tremendously in tracing performance and normal bootup. One
thing that you need to understand though. That daemon needs to call
kstop_machine to do the modifications. The daemon wakes up once a second,
checks to see if there is any new functions that have been recorded. If
not, then it simply goes back to sleep. But if there are new functions,
then it calls kstopmachine. This daemon stops when tracing is enabled, but
can cause unsuspecting latencies when tracing is disabled.

I'll probably add a something to disable the daemon just before firing off
init if PREEMPT_RT is enabled.

Any questions on porting ftrace, feel free to ask.

Cheers,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/