Re: Ftrace for Microblaze - notrace

From: Michal Simek
Date: Tue Nov 03 2009 - 13:13:33 EST

Steven Rostedt wrote:
On Tue, 2009-11-03 at 17:45 +0100, Michal Simek wrote:
Steven Rostedt wrote:

The next thing is about annotation notrace. I look at all arch. Is there any algorithm which function should use it? I think that this could be a reason why I my kernel freeze when enable function tracer.

I tested to add -pg flag for process.c file and after it kernel freeze too. Is it mean that problem could be there?
Is there any manual or instruction which functions are dangerous and especially why?

No there's no manual. It varies from arch to arch. Hmm, maybe I'll
update the current doc to have some of the issues that come with it.
(more info farther down)

yes, will be helpful - anyway I found missing references to ftrace-implementation.txt

kernel/trace/Kconfig:15: See Documentation/trace/ftrace-implementation.txt
kernel/trace/Kconfig:20: See Documentation/trace/ftrace-implementation.txt
kernel/trace/Kconfig:25: See Documentation/trace/ftrace-implementation.txt
kernel/trace/Kconfig:37: See Documentation/trace/ftrace-implementation.txt
kernel/trace/Kconfig:42: See Documentation/trace/ftrace-implementation.txt
kernel/trace/Kconfig:47: See Documentation/trace/ftrace-implementation.txt
kernel/trace/Kconfig:55: See Documentation/trace/ftrace-implementation.txt

And that will keep the process.c from being compiled with it. There may
be other files in the arch that should not have it. There's several in
x86 and in PowerPC.
Do you know why they exclude it?

I did the ports for x86 and PowerPC so I guess I'm the best to answer
this ;-)

I hope so.

In arch/x86 we have these removing -pg:

tsc.o, rtc.o - Do not trace clock output. The tracer itself uses it.
Even though it protects against recursion, it is a big overhead to trace
something within the tracer.

paravirt-spinlocks.o - paravirt does crazy things with locks and such,
but overwriting text. Don't add mcount to them and overwrite the text
with the ftrace facility.

ftrace.o - well duh ;-)

early_printk.o - This is mostly used for debugging, don't trace it.

cpu/common.o - This is used in early stages of boot up of secordary
CPUs. As well as used in hot plug. Simply using something like
smp_processor_id() can crash the kernel here. The tracer code uses that,
so don't trace it.

Xen has a bunch that they added, and I think that's also because they do
funny things too.

For powerpc, we have:

cputable.o, prom_init.o, btext.o and prom.o that are all very sensitive
with boot up code. Simply calling mcount here can crash the system. But
this prevents boot up. It does not lock up the kernel when we enable
function tracing.

ftrace.o - again, this should be obvious.

time.o - this is the same reason we don't trace tsc and rtc in x86.

ok In general - all timing functions and function which are related with startup code - called only once before turning on irqs - there are a lot of functions. I understand that make no sense to trace that files. And plus all debugging functions. And function which uses locks.
Anything else?

Can I use any special debug features? I mean I look at kernel.h and there are some trace_printk function - but they don't work for me. Is it possible to use them or not?

Should work. That's not arch dependent. But you need to have some ftrace
enabled. Enable CONFIG_CONTEXT_SWITCH_TRACER, and trace_printk should
work. That writes to the ring buffer and you can see the output
in /debug/tracing/trace.

It could be nice features but in case that you have command line and you can read that trace debug output. I mean any printk messages - which not contain any trace facility - just pure printk to console. Are that messages written to any place which could be read from debuger? Like log buffer? Is there any place for them?

The second things is that I haven't implemented save_stack_trace function - it is just while(1) loop. My kernel not jumps to this function that's why I am not interested to implement it. Am I right that ftrace code don't use it? Or the standard behavior is that ftrace code use this function and really care about. Does your kernel use that function?

From my test I don't understand MCOUNT_INSN_SIZE - and which function doesn't care about. There is this line of pseudocode in your doc
(unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;) but what the reason is to do that. If I understand correct selfpc and frompc just give addresses which functions called that mcount and has impact to log.
I mean that if that address is not proper begin of function is found (not sure if the code do it or not) function name (and function) which contain that address. Or is there any special reason why to substract that MCOUNT_INSN_SIZE - for timing or anything like that?

I simple just not find any reason for it. And I believe that don't have connection with my problem.


-- 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
Please read the FAQ at