[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090827073139.GB2131@elte.hu>
Date: Thu, 27 Aug 2009 09:31:39 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...hat.com>,
Avi Kivity <avi@...hat.com>, Andi Kleen <ak@...ux.intel.com>,
Christoph Hellwig <hch@...radead.org>,
"Frank Ch. Eigler" <fche@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, Jason Baron <jbaron@...hat.com>,
Jim Keniston <jkenisto@...ibm.com>,
"K.Prasad" <prasad@...ux.vnet.ibm.com>,
Lai Jiangshan <laijs@...fujitsu.com>,
Li Zefan <lizf@...fujitsu.com>,
Przemys??aw Pawe??czyk <przemyslaw@...elczyk.it>,
Roland McGrath <roland@...hat.com>,
Sam Ravnborg <sam@...nborg.org>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tom Zanussi <tzanussi@...il.com>,
Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: [PATCH 08/18] tracing: Add kprobe-based event tracer
* Frederic Weisbecker <fweisbec@...il.com> wrote:
> From: Masami Hiramatsu <mhiramat@...hat.com>
>
> Add kprobes-based event tracer on ftrace.
>
> This tracer is similar to the events tracer which is based on
> Tracepoint infrastructure. Instead of Tracepoint, this tracer is
> based on kprobes (kprobe and kretprobe). It probes anywhere where
> kprobes can probe(this
> means, all functions body except for __kprobes functions).
>
> Similar to the events tracer, this tracer doesn't need to be
> activated via current_tracer, instead of that, just set probe
> points via /sys/kernel/debug/tracing/kprobe_events. And you can
> set filters on each probe events via
> /sys/kernel/debug/tracing/events/kprobes/<EVENT>/filter.
ok, one observation here: this should seemlessly merge into
/debug/tracing/events/ and provide a record format descriptor in
'format' to allow the automated fetching of the results of the
probe. The PERF_SAMPLE_RAW gateway should work as well.
That way tooling that knows about /debug/tracing/events/ will
automatically work with kprobes events as well. We can profile based
on kprobes, etc. etc.
The _setting_ of the probe is still a separate channel - but if
existing installed probes are merged into existing tooling that's a
big step forward in terms of utility.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists