public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
		lkml <linux-kernel@vger.kernel.org>,
		Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
		Andi Kleen <ak@linux.intel.com>,
		Christoph Hellwig <hch@infradead.org>,
		"Frank Ch. Eigler" <fche@redhat.com>,
		"H. Peter Anvin" <hpa@zytor.com>,
	Jason Baron <jbaron@redhat.com>,
		Jim Keniston <jkenisto@us.ibm.com>,
		"K.Prasad" <prasad@linux.vnet.ibm.com>,
		Lai Jiangshan <laijs@cn.fujitsu.com>,
		Li Zefan <lizf@cn.fujitsu.com>,
		Peter Zijlstra <peterz@infradead.org>,
		Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
		Tom Zanussi <tzanussi@gmail.com>,
		systemtap <systemtap@sources.redhat.com>,
		DLE <dle-develop@lists.sourceforge.net>
Subject: Re: [PATCH tracing/kprobes 0/7] tracing/kprobes: kprobe-based 	event tracer update and perf support
Date: Fri, 11 Sep 2009 01:33:00 -0000	[thread overview]
Message-ID: <20090911013332.GB16396@nowhere> (raw)
In-Reply-To: <20090910235258.22412.29317.stgit@dhcp-100-2-132.bos.redhat.com>

On Thu, Sep 10, 2009 at 07:52:58PM -0400, Masami Hiramatsu wrote:
> Hi Frederic,
> 
> This series fixes bugs and upgrades kprobe-based event tracer
> as a dynamic event tracer on ftrace/perf tools. This also enhances
> tracer output format to show each argument name and event name on
> each entry.
> 
> With this series, users can add trace events dynamically on ftrace
> and use those events with perf tools as below.
> 
> (Step.1) Define new events under new group
> 
> $ echo p:mygroup/myprobe do_sys_open dfd=a0 filename=a1 flags=a2 mode=a3 \
>  > /debug/tracing/kprobes_events
> $ echo r:mygroup/myretprobe do_sys_open rv >> /debug/tracing/kprobes_events
> $ cat /debug/tracing/kprobes_events
> p:myprobe do_sys_open+0 dfd=a0 filename=a1 flags=a2 mode=a3
> r:myretprobe do_sys_open+0 rv=rv
> 
> (You can see that each argument has its name.)
> 
> 
> (Step.2) Perf shows new events
> 
> $ perf list
> ...
>    mygroup:myretprobe                         [Tracepoint event]
>    mygroup:myprobe                            [Tracepoint event]
> ...
> 
> 
> (Step.3) Record events with perf
> 
> $ perf record -f -e mygroup:myprobe:record -F 1 -a ls
> ...
> [ perf record: Captured and wrote 0.081 MB perf.data (~3544 samples) ]
> 
> 
> (Step.4) Perf trace shows the result
> 
> $ perf trace
> version = 0.5
>             perf-1405  [000]     0.000000: myprobe: (c04b0a5c) dfd=ffffff9c filename=810d3f7 flags=98800 mode=1
>             perf-1405  [000]     0.000000: myprobe: (c04b0a5c) dfd=ffffff9c filename=bff7650c flags=8000 mode=1b6
>             perf-1405  [000]     0.000000: myprobe: (c04b0a5c) dfd=ffffff9c filename=bff7650c flags=98800 mode=bff7450c
>             perf-1405  [000]     0.000000: myprobe: (c04b0a5c) dfd=ffffff9c filename=bff7650c flags=8000 mode=1b6


Nice!

May be another step in the todo-list that would be nice: define the format
for a type. Like it's done from ftrace events.


> 
> 
> (Step.5) You can also use return probes.
> 
> $ perf record -f -e mygroup:myretprobe:record -F 1 -a ls
> ...
> [ perf record: Captured and wrote 0.081 MB perf.data (~3544 samples) ]
> $ perf trace
> version = 0.5
>             perf-1408  [000]     0.000000: myretprobe: (c04b0a5c <- c04b0b7d) rv=b
>             perf-1408  [000]     0.000000: myretprobe: (c04b0a5c <- c04b0b7d) rv=c
>             perf-1408  [000]     0.000000: myretprobe: (c04b0a5c <- c04b0b7d) rv=d
>             perf-1408  [000]     0.000000: myretprobe: (c04b0a5c <- c04b0b7d) rv=c
> 
> 
> TODO:
> - Implement perf kprobe command to help defining new probes.



Yeah!

I wonder what could be the best workflow to use it.

Imagine the following steps:

- perf kprobe = define kprobes using C expression
- perf record -e our_kprobes
- perf trace

That's way too much.
Especially it's sad to be forced to define a kprobe, then
get back its name, use it with record, and eventually
unsheathe perf trace.

I guess we should choose between the low level, very granular
but uninviting method "kprobe + record + trace" and also an all
in one quick approach.

And that could be chosen from perf kprobe:

Low level:

perf kprobe --define-only [-p|-r] [probe_name] -a1 [arg1] -a2 [arg2] \
	    --format="%s %...."

perf record -e kprobes:probe_name
perf trace

Quick:

perf kprobe -p probe_name -a1 ..... cmdline| -a

And after the profiled task is finished, it could launch perf trace
by itself (or wait for a Ctrl + C if -a/wide profiling)

Well, it's just a brainstorming, having the low level method first
would be already a very nice thing.

I'm really looking forward seeing this C expression-like kprobe creation
tool.

It seems powerful enough to replace printk + kernel rebuild.

No need anymore to write some printk to debug, worrying,
sweating, feeling guilty because we know we'll need yet another
printk() after the reboot, and we even already know where while
it is compiling.

We would build less kernels, then drink less coffee, becoming
less nervous, more friendly. Everyone will offer flowers in
the street, the icebergs will grow back and white bears will...

And eventually we'll be inspired enough to write perf love,
the more than expected tool to post process ftrace "love" events.

Thanks,
Frederic.

  parent reply	other threads:[~2009-09-11  1:33 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-10 23:51 Masami Hiramatsu
2009-09-10 23:51 ` [PATCH tracing/kprobes 3/7] tracing/kprobes: Cleanup kprobe tracer code Masami Hiramatsu
2009-09-11  2:33   ` Daniel Walker
2009-09-11  2:36     ` Frederic Weisbecker
2009-09-10 23:51 ` [PATCH tracing/kprobes 4/7] tracing/kprobes: Add event profiling support Masami Hiramatsu
2009-09-11  3:13   ` Frederic Weisbecker
2009-09-11 16:18     ` Masami Hiramatsu
2009-09-14  3:02       ` Frederic Weisbecker
     [not found]         ` <4AAE7540.9090009@redhat.com>
2009-09-14 18:55           ` Frederic Weisbecker
     [not found]             ` <4AAE9B41.3020905@redhat.com>
2009-09-14 21:07               ` Frederic Weisbecker
2009-09-15  4:52                 ` Ananth N Mavinakayanahalli
2009-09-11 19:26     ` Masami Hiramatsu
2009-09-14  3:08       ` Frederic Weisbecker
2009-09-13 10:07     ` [BUGFIX] kprobes: prevent re-registration of the same kprobe Ananth N Mavinakayanahalli
     [not found]       ` <4AADA0BB.4030307@redhat.com>
2009-09-14 10:05         ` [BUGFIX] kprobes: prevent re-registration of the same kprobe - take2 Ananth N Mavinakayanahalli
     [not found]           ` <4AAE6E85.9020002@redhat.com>
2009-09-15  5:19             ` Ananth N Mavinakayanahalli
2009-09-16 23:52               ` Masami Hiramatsu
2009-09-10 23:51 ` [PATCH tracing/kprobes 1/7] x86/ptrace: Fix regs_get_argument_nth() to add correct offset Masami Hiramatsu
2009-09-11  1:43   ` Steven Rostedt
2009-09-10 23:51 ` [PATCH tracing/kprobes 2/7] tracing/kprobes: Fix probe offset to be unsigned Masami Hiramatsu
2009-09-10 23:51 ` [PATCH tracing/kprobes 5/7] tracing/kprobes: Add argument name support Masami Hiramatsu
2009-09-11 14:08   ` Steven Rostedt
2009-09-11 16:07     ` Masami Hiramatsu
2009-09-11 16:28       ` Masami Hiramatsu
2009-09-10 23:52 ` [PATCH tracing/kprobes 7/7] tracing/kprobes: Support custom subsystem for each kprobe event Masami Hiramatsu
2009-09-10 23:52 ` [PATCH tracing/kprobes 6/7] tracing/kprobes: Show event name in trace output Masami Hiramatsu
2009-09-11  1:33 ` Frederic Weisbecker [this message]
2009-09-11  1:45   ` [PATCH tracing/kprobes 0/7] tracing/kprobes: kprobe-based event tracer update and perf support Steven Rostedt
2009-09-11 15:59   ` Masami Hiramatsu
2009-09-14  3:00     ` Frederic Weisbecker
     [not found]       ` <4AAE7A5D.8010503@redhat.com>
2009-09-14 20:53         ` Frederic Weisbecker
     [not found]           ` <4AAEB149.2070300@redhat.com>
2009-09-14 21:09             ` Frederic Weisbecker
2009-09-11 19:03   ` Frank Ch. Eigler
2009-09-11 19:07     ` Christoph Hellwig
2009-09-11 19:51       ` Mark Wielaard
     [not found]         ` <20090911200317.GA3827@infradead.org>
2009-09-12  1:20           ` Masami Hiramatsu
2009-09-11 19:15     ` Frederic Weisbecker
2009-09-11 15:36 ` Frederic Weisbecker
2009-09-11 21:44   ` Masami Hiramatsu
2009-09-14  2:23     ` Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090911013332.GB16396@nowhere \
    --to=fweisbec@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=ananth@in.ibm.com \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=fche@redhat.com \
    --cc=hch@infradead.org \
    --cc=hpa@zytor.com \
    --cc=jbaron@redhat.com \
    --cc=jkenisto@us.ibm.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=tzanussi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).