[RFC PATCH 0/1] trace: Add early event trace support

[RFC PATCH 0/1] trace: Add early event trace support

[Ezequiel Garcia]

Hi Steven,

This patch is my first attempt to address the "early tracing issue".
Right now, trace events are registered on fs_initcall, which is very late
if you want to capture boot-up events.

This feature is in developers wish list as this old (2009) thread shows [1].

By splitting the initialization, separating the ftrace enable from the
sysfs entry
creation, it is possible to move events enable to early_initcall.
(which is also late, but I wouldn't expect more from such a small patch).

Without this patch, and using
"trace_event=kmem:kmalloc,kmem:kmalloc_node,kmem:kfree"
as kernel parameter, on a bare kernel I can start capturing kmallocs
from ~0.4 secs,
and I get 186 callers.

This patch moves the capture to ~ 0.2 secs and captures 220 callers.

The caller count is inaccurate since gcc does some automatic inlining
(I have another RFC PATCH for that), but it shows a rough increase.

Also, this enable is not time-consuming:
[    0.190000] calling  event_trace_enable+0x0/0xad @ 1
[    0.190000] initcall event_trace_enable+0x0/0xad returned 0 after 0 usecs

This patch is intended to trigger this discussion: to be honest I'm
not sure how ugly
this is. So some feedback about it would be greatly appreciated.

Also, I'd like to ask for some guidelines (not solutions, just some guidelines)
on how to attack this problem.
I'm interesting on capturing kmem events, from the very first kmalloc onwards.
Though, it would be nice to extend the solution to other event classes.

Thanks,
Ezequiel.

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0911.3/00036.html

Re: [RFC PATCH 0/1] trace: Add early event trace support

[Ezequiel Garcia]

On Wed, Aug 15, 2012 at 12:20 PM, Ezequiel Garcia <elezegarcia@gmail.com> wrote:
> Hi Steven,
>
> This patch is my first attempt to address the "early tracing issue".
> Right now, trace events are registered on fs_initcall, which is very late
> if you want to capture boot-up events.
>
> This feature is in developers wish list as this old (2009) thread shows [1].
>
> By splitting the initialization, separating the ftrace enable from the
> sysfs entry
> creation, it is possible to move events enable to early_initcall.
> (which is also late, but I wouldn't expect more from such a small patch).
>
> Without this patch, and using
> "trace_event=kmem:kmalloc,kmem:kmalloc_node,kmem:kfree"
> as kernel parameter, on a bare kernel I can start capturing kmallocs
> from ~0.4 secs,
> and I get 186 callers.
>
> This patch moves the capture to ~ 0.2 secs and captures 220 callers.
>
> The caller count is inaccurate since gcc does some automatic inlining
> (I have another RFC PATCH for that), but it shows a rough increase.
>
> Also, this enable is not time-consuming:
> [    0.190000] calling  event_trace_enable+0x0/0xad @ 1
> [    0.190000] initcall event_trace_enable+0x0/0xad returned 0 after 0 usecs
>
> This patch is intended to trigger this discussion: to be honest I'm
> not sure how ugly
> this is. So some feedback about it would be greatly appreciated.
>
> Also, I'd like to ask for some guidelines (not solutions, just some guidelines)
> on how to attack this problem.
> I'm interesting on capturing kmem events, from the very first kmalloc onwards.
> Though, it would be nice to extend the solution to other event classes.
>
> Thanks,
> Ezequiel.
>
> [1] http://lkml.indiana.edu/hypermail/linux/kernel/0911.3/00036.html


I forgot to add this work is part of a project funded by CE workgroup.
You can find more details here:

http://elinux.org/Kernel_dynamic_memory_allocation_tracking_and_reduction

Thanks,
Ezequiel.

Re: [RFC PATCH 0/1] trace: Add early event trace support

[Steven Rostedt]

On Wed, 2012-08-15 at 16:37 -0300, Ezequiel Garcia wrote:

> 
> I forgot to add this work is part of a project funded by CE workgroup.
> You can find more details here:
> 
> http://elinux.org/Kernel_dynamic_memory_allocation_tracking_and_reduction
> 

Thanks,

I'll try to get some time tomorrow to look a this. I'm currently in the
middle of upgrading several boxes, and I'm stuck spending the entire day
on IT.

-- Steve