Re: [17/19] ftrace: dynamic enabling/disabling of function calls

Previous thread: [16/19] ftrace: trace preempt off critical timings by Ingo Molnar on Sunday, February 10, 2008 - 3:21 am. (1 message)

Next thread: [18/19] ftrace: add ftrace_enabled sysctl to disable mcount function by Ingo Molnar on Sunday, February 10, 2008 - 3:21 am. (1 message)
To: <linux-kernel@...>
Cc: Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>, Steven Rostedt <rostedt@...>
Date: Sunday, February 10, 2008 - 3:21 am

From: Steven Rostedt <srostedt@redhat.com>

This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.

The way this works, is on bootup, a ftrace function is registered
to record the instruction pointer of all places that call the
function.

Later, a kthread is awoken once a second that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time.

e.g.

call ftrace /* 5 bytes */

is replaced with

jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:

When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.

Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.

Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/Makefile | 1
arch/x86/kernel/ftrace.c | 237 +++++++++++++++++++++++++++++++
include/linux/ftrace.h | 18 ++
kernel/trace/Kconfig | 17 ++
kernel/trace/ftrace.c | 356 ++++++++++++++++++++++++++++++++++++++++++-----
5 files changed, 597 insertions(+), 32 deletions(-)

Index: linux/arch/x86/kernel/Mak...

To: Ingo Molnar <mingo@...>, Steven Rostedt <rostedt@...>
Cc: <linux-kernel@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>
Date: Monday, February 11, 2008 - 11:35 am

Hi Ingo and Steven,

I'd like to suggest that you can use djprobe-like solution here to eliminate
stop_machine.
The djprobe makes a bypass over that call instruction by using a kprobe,
and after replacing the call instruction, you can safely remove the bypass.
Here is an ols paper about djprobe.
http://www.kernel.org/doc/ols/2007/ols2007v1-pages-189-200.pdf

Thank you,

--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

--

To: Masami Hiramatsu <mhiramat@...>
Cc: Steven Rostedt <rostedt@...>, <linux-kernel@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>
Date: Monday, February 11, 2008 - 12:31 pm

i think the stop_machine() method for code patching is pretty elegant in
that it reuses an otherwise rarely used but critical facility. We want
it to be fast and easy, and our current ftrace testing shows that it is.
So unless there are strong reasons to do otherwise, it would be nice to
keep that approach :-)

Ingo
--

Previous thread: [16/19] ftrace: trace preempt off critical timings by Ingo Molnar on Sunday, February 10, 2008 - 3:21 am. (1 message)

Next thread: [18/19] ftrace: add ftrace_enabled sysctl to disable mcount function by Ingo Molnar on Sunday, February 10, 2008 - 3:21 am. (1 message)