FUNCTION_TRACER: can it be used to trace early bootup functions

FUNCTION_TRACER: can it be used to trace early bootup functions

[Iram Shahzad]

Hi

I would like to know whether the Kernel Function Tracer
(kernel/trace/trace_functions) be used to trace early kernel
bootup functions starting from start_kernel?
My arch is ARM, by the way.

I have done some trials but it doesn't seem to trace early
bootup functions. I even made it the default tracer replacing
the nop tracer, but still it doesn't give me trace from
start_kernel.

Looking at the source code, it seems to me that it starts
recording data only after its own initialization. So does it
mean that by design it does not support early tracing?

Please CC me in the reply.

Thanks in advance
Iram

Re: FUNCTION_TRACER: can it be used to trace early bootup functions

[Tim Bird]

On 05/23/2010 11:55 PM, Iram Shahzad wrote:
> Hi
> 
> I would like to know whether the Kernel Function Tracer
> (kernel/trace/trace_functions) be used to trace early kernel
> bootup functions starting from start_kernel?
> My arch is ARM, by the way.
>
> 
> I have done some trials but it doesn't seem to trace early
> bootup functions. I even made it the default tracer replacing
> the nop tracer, but still it doesn't give me trace from
> start_kernel.
> 
> Looking at the source code, it seems to me that it starts
> recording data only after its own initialization. So does it
> mean that by design it does not support early tracing?
By design, the trace code is initialized during
initcall processing.  This means you miss all initialization
up to this point in the kernel.

Measuring this on my own ARM platforms, I have found that
this results in missing about the first 50 milliseconds
of kernel initialization (from start_kernel() to the
tracer initialization).  For me, this is not a big
problem.  Note that you can't measure the period
of time from start_kernel() to whenever the ARM memory
and clocks are initialized.

IMHO the best way to measure stuff between the end
of bootloader and tracer initialization is with an
external tracer, like http://elinux.org/Grabserial
and using CONFIG_DEBUG_LL, and your own calls to
printascii() on ARM.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Network Entertainment
=============================

Re: FUNCTION_TRACER: can it be used to trace early bootup functions

[Iram Shahzad]

Tim

Many thanks for the information. I am sorry I did not mention
that my purpose this time is to know the calling sequence of the
functions rather than to measure the timings.
Anyway the information is useful to me.

It seems there is another tracing mechanism called KFT.
http://elinux.org/Kernel_Function_Trace
>From the examples in the above URL, it looks like it can
start tracing from start_kernel.
But it seems it is neither mainlined nor actively maintained.
Any idea about its status?

Thanks
Iram

Re: FUNCTION_TRACER: can it be used to trace early bootup functions

[Steven Rostedt]

On Mon, 2010-05-24 at 15:55 +0900, Iram Shahzad wrote:
> Hi
> 
> I would like to know whether the Kernel Function Tracer
> (kernel/trace/trace_functions) be used to trace early kernel
> bootup functions starting from start_kernel?
> My arch is ARM, by the way.
> 
> I have done some trials but it doesn't seem to trace early
> bootup functions. I even made it the default tracer replacing
> the nop tracer, but still it doesn't give me trace from
> start_kernel.
> 
> Looking at the source code, it seems to me that it starts
> recording data only after its own initialization. So does it
> mean that by design it does not support early tracing?

The main reason it does not support early tracing is that we need memory
management initialized before we can setup tracing. The tracing needs to
go somewhere :-)

With my previous tracer (logdev) I had a way to initialize the ring
buffer via bootmem. This allowed for tracing as soon as bootmem could be
allocated.

It is still feasible to add a way to do function tracing with bootmem, I
just never got around to it.

> 
> Please CC me in the reply.

Don't worry, that's the default way for LKML ;-)

-- Steve