From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] tracing/function-graph-tracer: tracing only syscalls mode
Date: Fri, 2 Jan 2009 20:40:14 +0100 [thread overview]
Message-ID: <20090102194014.GI14249@elte.hu> (raw)
In-Reply-To: <495abce9.0baa660a.04de.60ae@mx.google.com>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> Impact: make more easy the syscalls tracing
>
> This patch extends to syscalls the features which let one to trace
> only one ore more function (and those they call).
> This way we can get rid of the workqueues, kernel threads, softirqs from
> ksoftirqd and only have the syscall path on the trace.
>
> Note that hardirq that interrupt the syscalls are still traced. But we could
> add an option to disable the interrupt tracing as well in the future.
>
> To use this new feature:
>
> echo function_graph > /debugfs/tracing/current_tracer
> echo syscalls > /debugfs/tracing/set_graph_function
nice. I think a key item is missing though:
> @@ -1397,6 +1398,9 @@ asmregparm long syscall_trace_enter(struct pt_regs *regs)
> {
> long ret = 0;
>
> + /* Tell the function graph tracer we are entering a system call */
> + ftrace_graph_syscall_enter();
We could actually trace the _syscalls_ themselves, a'la strace:
munmap(0xb7ff3000, 4096) = 0
So instead of the current ftrace output:
0) cc1-30212 | | sys32_mmap2() {
0) cc1-30212 | | down_write() {
0) cc1-30212 | 0.272 us | _spin_lock_irq();
0) cc1-30212 | 0.969 us | }
0) cc1-30212 | | do_mmap_pgoff() {
We could get something like:
0) cc1-30212 | | sys32_mmap2(0xb7ff3000, 4096) {
0) cc1-30212 | | down_write() {
0) cc1-30212 | 0.272 us | _spin_lock_irq();
0) cc1-30212 | 0.969 us | }
0) cc1-30212 | | do_mmap_pgoff() {
[...]
0) cc1-30212 | + 22.537 us | } = 0
Or maybe as separate trace entries:
0) cc1-30212 | |> sys32_mmap2 [0xb7ff3000, 4096]
0) cc1-30212 | | sys32_mmap2 {
0) cc1-30212 | | down_write() {
0) cc1-30212 | 0.272 us | _spin_lock_irq();
0) cc1-30212 | 0.969 us | }
0) cc1-30212 | | do_mmap_pgoff() {
[...]
0) cc1-30212 | + 22.537 us | }
0) cc1-30212 | |< sys32_mmap2 => 0
For that we'd have to pass in something like the syscall function address
(sys_call_table[regs->ax]), and the up to 6 parameters
[regs->bx,cx,dx,si,di,bp].
(and initially we could just print all of them i guess, instead of a
variable-width thing)
We wouldnt do smart decoding of syscall arguments normally - just print
the raw arguments with no decoding. (like strace -e raw=all)
How does this sound?
Ingo
next prev parent reply other threads:[~2009-01-02 19:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 0:29 [PATCH] tracing/function-graph-tracer: tracing only syscalls mode Frederic Weisbecker
2009-01-02 19:40 ` Ingo Molnar [this message]
2009-01-02 21:28 ` Frederic Weisbecker
2009-01-05 19:11 ` Steven Rostedt
2009-01-05 23:57 ` 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=20090102194014.GI14249@elte.hu \
--to=mingo@elte.hu \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.