public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: [RFC v3][PATCH 0/2] Make ftrace able to trace function return
Date: Tue, 11 Nov 2008 06:46:25 +0100	[thread overview]
Message-ID: <49191C31.1050402@gmail.com> (raw)

This patchset adds the ability for ftrace to trace the function even on call time and on
return time. So we can now measure the time of execution of the most part of the functions
inside the kernel with ftrace.

The first patch bring the low level tools to add the support of return tracing on X86-32. It is
totally separated from the traditional implementation of ftrace and doesn't support
dynamic ftrace at this time.

The second patch adds a tracer based on the ring-buffer which measure the time of execution of the functions inside the kernel.

---

Most of the changes in this V3 have been suggested by Steven Rostedt.
The low-level function handling uses now the thread info and use a stack-style
storage of addresses. So it can follow the call stack. This implementation uses
a maximum depth of 20 calls per thread.
This is much more scalable than the old trampoline based implementation because
each thread has its own stack of return addresses. There should be lesser overruns
(cases when the tracer have to drop one trace because there is no more slot to store
the return address).
NMIs are still not supported but you can now trace even if the watchdog is enabled (functions
called in NMI context will not be traced).

There are other changes that are described below.
---

Changelog[V3]:

_CONFIG_FTRACE_RETURN depends now on CONFIG_FUNCTION_TRACER.
_ftrace_return_stub disappears to use now ftrace_stub
_Use a simplified version of the nmi context detection by ftrace
 to not trace in nmi context.
_Warn and disable tracing if fault or if the return address is not in kernel text.
_Get rid of the trampoline to use the thread_info of a task to store return addresses.
 A task get its stack of return addresses initialized in two cases:
    _ The init task begins with an empty stack of return adresses
    _ When a process forks, its child obtains an empty stack of return addresses because it will begin
      its execution in userspace and doesn't need the memorized return adresses of its parent.
_ The return_to_handler execute in two states: a first part in assembly that save appropriate registers
  (return values) and jump to the original return adresse. The second part retrieve the return address,
  send the trace and return the address.
_Use CFLAGS_REMOVE for some files when CONFIG_FTRACE_RETURN is set to let function tracer still able
 to trace its functions. V2 used notrace.
_Correct a bug during trace insertion where "disabled" wasn't well verified.
_Move case statement of the printing for return traces on trace.c to call the function provided by the
 return tracer. So other tracers can now use it.

Project of future improvements:

_ Set a more fine grained locking when touching the return addresses trace stack.
  The actual lock uses a global spinlock for all the stack of each thread.
  It would be better to set one spinlock per thread or even use a lockless solution
  based on atomic operations to manipulate the index on the stack.

_ Passing arguments to prepare_ftrace_return by register instead of using the stack. (faster)

_ Let the ftrace API to assign more than one return handler.

_ Implement return tracing on X86-64 and ARM.

Changelog[V2]:

_ Fix deadlock caused by NMI (disable tracing if watchdog is active)
_ Fix return value when it is 64 bits wide.
_ First really working version


Stats for the V3:
---
 arch/x86/Kconfig                      |    1 +
 arch/x86/include/asm/ftrace.h         |   26 +++++
 arch/x86/include/asm/thread_info.h    |   24 +++++
 arch/x86/kernel/Makefile              |    6 +
 arch/x86/kernel/entry_32.S            |   33 ++++++
 arch/x86/kernel/ftrace.c              |  181 +++++++++++++++++++++++++++++++--
 include/linux/ftrace.h                |   20 ++++
 include/linux/ftrace_irq.h            |    2 +-
 include/linux/sched.h                 |   11 ++
 kernel/Makefile                       |    4 +
 kernel/trace/Kconfig                  |   14 +++
 kernel/trace/Makefile                 |    1 +
 kernel/trace/ftrace.c                 |   16 +++
 kernel/trace/trace.c                  |   65 ++++++++++--
 kernel/trace/trace.h                  |   35 +++++++
 kernel/trace/trace_functions_return.c |   82 +++++++++++++++
 16 files changed, 505 insertions(+), 16 deletions(-)

             reply	other threads:[~2008-11-11  5:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-11  5:46 Frederic Weisbecker [this message]
2008-11-11  9:43 ` [RFC v3][PATCH 0/2] Make ftrace able to trace function return Ingo Molnar
2008-11-11 10:12   ` [PATCH] tracing, x86: function return tracer, fix assembly constraints Ingo Molnar
2008-11-11 11:04   ` [PATCH] tracing: function return tracer, build fix Ingo Molnar
2008-11-11 15:30   ` [RFC v3][PATCH 0/2] Make ftrace able to trace function return Frédéric Weisbecker
2008-11-11 17:14     ` Ingo Molnar
2008-11-11 17:24       ` Frédéric Weisbecker
2008-11-11 18:43         ` Ingo Molnar
2008-11-11 19:14           ` Frédéric Weisbecker
2008-11-12 20:44 ` Frank Ch. Eigler
2008-11-13  0:10   ` Frédéric 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=49191C31.1050402@gmail.com \
    --to=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox