Re: [RFC][PATCH -tip 0/5 V2] tracing: kprobe-based event tracer

Masami Hiramatsu
2009-03-21T21:19:58Z

Andrew Morton wrote:
> On Fri, 20 Mar 2009 21:33:21 -0400 Masami Hiramatsu <mhiramat@redhat.com> wrote:
>
>> echo /debug/tracing/trace
>
> Should be cat, I assume?

Ah, yes, thanks!

>> # tracer: nop
>> #
>> # TASK-PID CPU# TIMESTAMP FUNCTION
>> # | | | | |
>> <...>-2376 [001] 262.389131: do_sys_open: @do_sys_open+0 0xffffff9c 0x98db83e 0x8880 0x0
>> <...>-2376 [001] 262.391166: sys_open: <-do_sys_open+0 0x5 0xc06e8ebb
>> <...>-2376 [001] 264.384876: do_sys_open: @do_sys_open+0 0xffffff9c 0x98db83e 0x8880 0x0
>> <...>-2376 [001] 264.386880: sys_open: <-do_sys_open+0 0x5 0xc06e8ebb
>> <...>-2084 [001] 265.380330: do_sys_open: @do_sys_open+0 0xffffff9c 0x804be3e 0x0 0x1b6
>> <...>-2084 [001] 265.380399: sys_open: <-do_sys_open+0 0x3 0xc06e8ebb
>
> Well... this is cool and all that, but nowhere near as useful as kgdb!
> Its main competition however will be plain old printk.

kgdb or other debugger might be able to use this tracer,
but this will provide just a low-level infrastructure.

> Do we really honestly think that this feature will be sufficiently useful
> to a sufficiently large number of kernel developers as to warrant
> inclusion?

No, I think it's just a starting point.

> Perhaps a bit more thought about some more complex use cases would help.
>
> And given that the users of this (and other tracing features) are general
> kernel developers rather than tracing (or kprobes) developers, it would be
> nice to get some feedback and even testing/usage results from those people.
> ie: everyone else.

I hope so,

Thank you!

--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com