From: Atsushi Tsuji <a-tsuji@bk.jp.nec.com>
To: linux-kernel@vger.kernel.org, rostedt@goodmis.org,
Ingo Molnar <mingo@elte.hu>,
fweisbec@gmail.com, "Frank Ch. Eigler" <fche@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
paulus@samba.org, systemtap@sources.redhat.com
Subject: [PATCH 0/2] tracing: Tracing integration - dynamic ftrace for SystemTap
Date: Tue, 15 Sep 2009 19:06:28 +0900 [thread overview]
Message-ID: <4AAF6724.9080201@bk.jp.nec.com> (raw)
Hi,
Currently, there are some tracers using in Linux. Each of them are
developed for different users and situations.
Ftrace has own probe mechanism, dynamic ftrace, and various plugins,
and it can be used without particular userland tools. It is suitable
for kernel developer. The performance counters have own userland tool
merged in the kernel tree and it's easy to trace kernel events by using
this tool. It is suitable for people who don't have enough knowledge
of internal kernel. SystemTap has own scripting language and users can
gather kernel internal information suited to their needs by customizing
the script. Since it also has features, the log rotation and the
initscript, to keep collecting information continually, it is suitable
for system administrator and enterprise users.
I think we need to use those tracers as the situation demands, since
no tracer exists to meet anyone's needs and to fit any situation.
Then, we should consider the tracing mechanisms (kprobe, dynamic ftrace
and etc. kernel tracing features) and tracers (user interface)
separately, and all tracers should be able to use each tracing mechanisms.
The mechanism of dynamic ftrace is useful for all tracers. However
only ftrace can currently use it. I think it can be used for other
tracers via register_ and unregister_ftrace_function_probe
function. By using it, the overhead of instrumentation can be reduced
and gathering information, which cannot be traced because of a large
overhead, become available. Also it can enable the performance
counters to count events for all kernel functions.
First, I sent patches to integrate ftrace and SystemTap by just exporting
ftrace API. Also I fixed minor bugs for __unregister_ftrace_function_probe.
The patches doesn't contain the performance counters integration,
since it is still in development. I think following implementations are
needed:
- add new type to perf_id (like PERF_TYPE_FTRACE)
- add event ids to struct dyn_ftrace
- add interfaces to reference event ids by user (via debugfs?)
- add probe function to count ftrace events (call do_perf_swcounter_event)
Those patches are for -tip tree.
Thanks,
Atsushi
Signed-off-by: Atsushi Tsuji <a-tsuji@bk.jp.nec.com>
---
kernel/trace/ftrace.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
next reply other threads:[~2009-09-15 10:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-15 10:06 Atsushi Tsuji [this message]
2009-09-15 10:15 ` [PATCH 0/2] tracing: Tracing integration - dynamic ftrace for SystemTap Peter Zijlstra
2009-09-15 10:19 ` Peter Zijlstra
2009-09-15 13:28 ` Steven Rostedt
2009-09-15 13:36 ` Peter Zijlstra
2009-09-16 8:08 ` Atsushi Tsuji
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=4AAF6724.9080201@bk.jp.nec.com \
--to=a-tsuji@bk.jp.nec.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=systemtap@sources.redhat.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