tracing/function-return-tracer: Support for dynamic ftrace on function return tracer
PATCH 4/4 tracing/function-return-tracer: Support for dynamic ftrace on function return tracer
This patch adds the support for dynamic tracing on the function return tracer. The whole difference with normal dynamic function tracing is that we don't need to hook on a particular callback. The only pro that we want is to nop or set dynamically the calls to ftrace_caller (which is ftrace_return_caller here).
Some security checks ensure that we are not trying to launch dynamic tracing for return tracing while normal function tracing is already running.
An example of trace with getnstimeofday set as a filter:
ktime_get_ts+0x22/0x50 -> getnstimeofday (2283 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1396 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1382 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1825 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1426 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1464 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1524 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1382 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1382 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1434 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1464 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1502 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1404 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1397 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1051 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1314 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1344 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1163 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1390 ns) ktime_get_ts+0x22/0x50 -> getnstimeofday (1374 ns)
--- arch/x86/kernel/entry_32.S | 18 ++- arch/x86/kernel/ftrace.c | 258 +++++++++++++++++---------------- include/linux/ftrace.h | 16 ++- kernel/trace/Kconfig | 1 - kernel/trace/ftrace.c | 58 +++++++- kernel/trace/trace_functions_return.c | 15 +-- 6 files changed, 211 insertions(+), 155 deletions(-)
arch/x86/kernel/entry_32.S +11 -7
@@ -1200,7 +1200,7 @@ ENTRY(mcount) jnz trace #ifdef CONFIG_FUNCTION_RET_TRACER cmpl $ftrace_stub, ftrace_function_return - jnz trace_return + jnz ftrace_return_caller #endif .globl ftrace_stub ftrace_stub:
@@ -1221,9 +1221,15 @@ trace: popl %ecx popl %eax jmp ftrace_stub +END(mcount) +#endif /* CONFIG_DYNAMIC_FTRACE */ +#endif /* CONFIG_FUNCTION_TRACER */ #ifdef CONFIG_FUNCTION_RET_TRACER -trace_return: +ENTRY(ftrace_return_caller) + cmpl $0, function_trace_stop + jne ftrace_stub + pushl %eax pushl %ecx pushl %edx
@@ -1233,7 +1239,8 @@ trace_return: popl %edx popl %ecx popl %eax - jmp ftrace_stub + ret +END(ftrace_return_caller) .globl return_to_handler return_to_handler:
@@ -1247,10 +1254,7 @@ return_to_handler: popl %ecx popl %eax ret -#endif /* CONFIG_FUNCTION_RET_TRACER */ -END(mcount) -#endif /* CONFIG_DYNAMIC_FTRACE */ -#endif /* CONFIG_FUNCTION_TRACER */ +#endif .section .rodata,"a" #include "syscall_table_32.S"
arch/x86/kernel/ftrace.c +130 -128
267 lines not on this page · raw message
include/linux/ftrace.h +15 -1
@@ -25,6 +25,17 @@ struct ftrace_ops {extern int function_trace_stop; +/* +* Type of the current tracing. +*/ +enum ftrace_tracing_type_t { +FTRACE_TYPE_ENTER =0 ,/* Hook the call of the function */ +FTRACE_TYPE_RETURN ,/* Hook the return of the function */ +}; + +/* Current tracing type, default is FTRACE_TYPE_ENTER */ +extern enum ftrace_tracing_type_t ftrace_tracing_type; +/** * ftrace_stop - stop function tracer. *
@@ -104,6 +115,9 @@ extern int ftrace_update_ftrace_func(ftrace_func_t func);extern void ftrace_caller (void );extern void ftrace_call (void );extern void mcount_call (void ); +#ifdef CONFIG_FUNCTION_RET_TRACER +extern void ftrace_return_caller (void ); +#endif /** * ftrace_make_nop - convert code into top
@@ -310,7 +324,7 @@ struct ftrace_retfunc {/* Type of a callback handler of tracing return function */ typedef void (*trace_function_return_t )(struct ftrace_retfunc *); -extern void register_ftrace_return (trace_function_return_t func); +extern int register_ftrace_return (trace_function_return_t func);/* The current handler in use */ extern trace_function_return_t ftrace_function_return;extern void unregister_ftrace_return (void );
kernel/trace/Kconfig +0 -1
@@ -59,7 +59,6 @@ config FUNCTION_TRACER config FUNCTION_RET_TRACER bool "Kernel Function return Tracer" - depends on !DYNAMIC_FTRACE depends on HAVE_FUNCTION_RET_TRACER depends on FUNCTION_TRACER help
kernel/trace/ftrace.c +53 -5
106 lines not on this page · raw message
kernel/trace/trace_functions_return.c +2 -13
@@ -14,29 +14,18 @@#include "trace.h" -static void start_return_trace (struct trace_array *tr) -{ -register_ftrace_return (&trace_function_return); -} - -static void stop_return_trace (struct trace_array *tr) -{ -unregister_ftrace_return (); -} -static int return_trace_init (struct trace_array *tr) {int cpu;for_each_online_cpu (cpu)tracing_reset (tr, cpu); -start_return_trace (tr); -return 0 ; +return register_ftrace_return (&trace_function_return); }static void return_trace_reset (struct trace_array *tr) { -stop_return_trace (tr); +unregister_ftrace_return (); }
Signature · 1 line
1.5.2.5
Steven Rostedt
maintainerkernel/trace/ftrace.c int register_ftrace_function(struct ftrace_ops *ops) · line 1425
Quoted 12 lines · Frederic Weisbecker
static void
ftrace_replace_code(int enable)kernel/trace/ftrace.c +6
-0@@ -1405,10 +1417,17 @@ int register_ftrace_function(struct ftrace_ops *ops)return -1 ;mutex_lock (&ftrace_sysctl_lock); + +if (ftrace_tracing_type ==FTRACE_TYPE_RETURN ) { + ret = -EBUSY ; + goto out; + } +
Why do we need to disable all new tracing functions when we do return tracing??
-- Steve
Quoted 9 lines
kernel/trace/ftrace.c +2
-1ret =__register_ftrace_function (ops);ftrace_startup (); -mutex_unlock (&ftrace_sysctl_lock); +out: +mutex_unlock (&ftrace_sysctl_lock);return ret; }
2008/11/24 Steven Rostedt <[email protected]>:
Quoted 18 lines · Frederic Weisbecker
kernel/trace/ftrace.c int register_ftrace_function(struct ftrace_ops *ops) · line 1425
Quoted 12 lines
static void
ftrace_replace_code(int enable)kernel/trace/ftrace.c +6
-0@@ -1405,10 +1417,17 @@ int register_ftrace_function(struct ftrace_ops *ops)return -1 ;mutex_lock (&ftrace_sysctl_lock); + +if (ftrace_tracing_type ==FTRACE_TYPE_RETURN ) { + ret = -EBUSY ; + goto out; + } +Why do we need to disable all new tracing functions when we do return tracing??
Quoted 12 lines
-- Steve
Quoted 9 lines
kernel/trace/ftrace.c +2
-1ret =__register_ftrace_function (ops);ftrace_startup (); -mutex_unlock (&ftrace_sysctl_lock); +out: +mutex_unlock (&ftrace_sysctl_lock);return ret; }
You will see the same test when trying to register a return handler, it verifies that normal ftrace is not running.
Otherwise it will fail.
I made ftrace and ftrace-return not abled to work simultaneously for the moment. That made the integration of ftrace-return into dynamic tracing much more simpler...
But if someone needs to enable both tracing at the same time, I can change it...
Steven Rostedt
maintainerQuoted 9 lines · Fr?d?ric Weisbecker
You will see the same test when trying to register a return handler, it verifies that normal ftrace is not running.
Otherwise it will fail.
I made ftrace and ftrace-return not abled to work simultaneously for the moment. That made the integration of ftrace-return into dynamic tracing much more simpler...But if someone needs to enable both tracing at the same time, I can change it...
I'm just trying to figure out why the two can not work together?
The function hooks are used by things other than tracing functions. The stack trace uses it too.
-- Steve
Quoted 28 lines · � wrote:
2008/11/24 Steven Rostedt <[email protected]>:
Quoted 15 lines · Frederic Weisbecker
kernel/trace/ftrace.c int register_ftrace_function(struct ftrace_ops *ops) · line 1425
Quoted 11 lines
static void
ftrace_replace_code(int enable)kernel/trace/ftrace.c +6
-0@@ -1405,10 +1417,17 @@ int register_ftrace_function(struct ftrace_ops *ops)return -1 ;mutex_lock (&ftrace_sysctl_lock); + +if (ftrace_tracing_type ==FTRACE_TYPE_RETURN ) { + ret = -EBUSY ; + goto out; + } +Why do we need to disable all new tracing functions when we do return tracing??
Quoted 11 lines
-- Steve
Quoted 9 lines
kernel/trace/ftrace.c +2
-1ret =__register_ftrace_function (ops);ftrace_startup (); -mutex_unlock (&ftrace_sysctl_lock); +out: +mutex_unlock (&ftrace_sysctl_lock);return ret; }
Quoted 8 lines
You will see the same test when trying to register a return handler, it verifies that normal ftrace is not running.
Otherwise it will fail.
I made ftrace and ftrace-return not abled to work simultaneously for the moment. That made the integration of ftrace-return into dynamic tracing much more simpler...But if someone needs to enable both tracing at the same time, I can change it...
Very sorry I'm coming to this thread late. I didn't notice it until today.
Not to question the whole approach, and sorry if this was discussed before, but why wasn't -finstrument-functions used to instrument the function exits. This worked well for KFT (See http://elinux.org/Kernel_Function_Trace). I'm not sure if the function prologue and epilogue modifications done by -mcount are different than -finstrument-functions, but I thought I remember something about Steven testing -finstrument-functions in an early version of ftrace.
By the way, I'm really excited to see this "function_cost" stuff being worked on. It has proven to be extremely useful for analyzing early boot latencies at Sony.
Sorry again I didn't catch this and previous related threads earlier. I have some post-processing tools which might be useful here. Also, I've found it very handy to have the capability to filter by minimum function duration. Is there any work to do that with the current system. If not, maybe I could take a look at that and see if I can add something.
Regards,
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America
=============================
Hi Tim,
2008/11/26 Tim Bird <[email protected]>:> � wrote:> Very sorry I'm coming to this thread late. I didn't notice it until> today.>> Not to question the whole approach, and sorry if this was> discussed before, but why wasn't -finstrument-functions used> to instrument the function exits. This worked well for KFT> (See http://elinux.org/Kernel_Function_Trace). I'm not sure if the> function prologue and epilogue modifications done by -mcount are> different than -finstrument-functions, but I thought I remember something> about Steven testing -finstrument-functions in an early version of ftrace.
Yes, we discussed it earlier but because of some reasons (kernel size,dynamic patchingcost), we used a stack of return address for each task.See the discussion about using -finstrument-functions:http://lkml.org/lkml/2008/10/30/372
Quoted 1 line
By the way, I'm really excited to see this "
function_cost" stuff being> worked on. It has proven to be extremely useful for analyzing early boot> latencies at Sony.>> Sorry again I didn't catch this and previous related threads> earlier. I have some post-processing tools which might be useful here.
That would be welcome. Note that the output of this tracer is a bit differentfrom KFT. I'm currently working on the a C-like output:http://lkml.org/lkml/2008/11/25/389So perhaps the post-processing would have to be done in a way quitedifferent from thisused on KFT traces. I don't know.
Quoted 1 line
Also, I've found it very handy to have the capability to filter by minimum> function duration. Is there any work to do that with the> current system. If not, maybe I could take a look at that and see if> I can add something.
Yes there would be some modifications to do so.I guess the best thing to do that would be to use the trace_optionsfiles in whichany tracer can set some custom flags. See set_flag callback in struct tracer.
For now, this file can only receive boolean value on particular options.For example if you have a tracepid option. You either echo tracepid ornotracepid toset the value on trace_option. Your needs would require this file, andthis set_flag callback,to receive string values, like kernel parameters, by using get_option().This way you could set duration=50 as an example.This work is more tracing specific than function-return-tracerspecific (it was renamed function_branchtracer recently). After that, handling this minimal duration set on function branchtracer will be pretty easy. :-)
One other solution would be to have a dedicated debugfs file for thistracer but that would be a pity, IMHO,to not let too other tracers having custom options with string values.
If you want to have a look on the current state, see the -tip tree.
I will add you in Cc for next patches....���{.n�+�������+%�����ݶ��w��{.n�+����{��G�����{ay� ʇڙ�,j��f���h��������z_�(�階�ݢj"���m������G������?����&���~��iO��z��v�^�m���� ������?�I�
Steven Rostedt
maintainer[
Sorry Tim to reply again, but alpine broke on Frederic's funny characters in his email address, and it chopped off all the Cc's :-(
]
Quoted 10 lines · Tim Bird
Very sorry I'm coming to this thread late. I didn't notice it until today.
Not to question the whole approach, and sorry if this was discussed before, but why wasn't -finstrument-functions used to instrument the function exits. This worked well for KFT (See http://elinux.org/Kernel_Function_Trace). I'm not sure if the function prologue and epilogue modifications done by -mcount are different than -finstrument-functions, but I thought I remember
something
Quoted 1 line
about Steven testing -finstrument-functions in an early version of
ftrace.
Quoted 3 lines
By the way, I'm really excited to see this "
function_cost" stuff being worked on. It has proven to be extremely useful for analyzing early
boot
Quoted 2 lines
latencies at Sony.
No prob Tim. I need to make a standard template to explain the reason not to use -finstrument-functions. (/me goes look for a previous post...)
Here it is:
(here's the original post: http://lkml.org/lkml/2008/10/30/372 that
was posted at the beginning of Frederic's work)
========================================================
Lets take a simple C file called traceme.c:
---
static int x;
void trace_me(void)
{
x++;
}---
Normal compiling of:
gcc -c traceme.c
produces:
00000000 <trace_me>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: a1 00 00 00 00 mov 0x0,%eax
4: R_386_32 .bss
8: 83 c0 01 add $0x1,%eax
b: a3 00 00 00 00 mov %eax,0x0
c: R_386_32 .bss
10: 5d pop %ebp
11: c3 ret With
gcc -c -pg traceme.c
00000000 <trace_me>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: e8 fc ff ff ff call 4 <trace_me+0x4>
4: R_386_PC32 mcount
8: a1 00 00 00 00 mov 0x0,%eax
9: R_386_32 .bss
d: 83 c0 01 add $0x1,%eax
10: a3 00 00 00 00 mov %eax,0x0
11: R_386_32 .bss
15: 5d pop %ebp
16: c3 ret The only difference between the two is an added "call mcount". 5 byte op to replace with dynamic ftrace.
But now lets look at:
gcc -c -finstrument-functions traceme.c
00000000 <trace_me>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 18 sub $0x18,%esp
6: 8b 45 04 mov 0x4(%ebp),%eax
9: 89 44 24 04 mov %eax,0x4(%esp)
d: c7 04 24 00 00 00 00 movl $0x0,(%esp)
10: R_386_32 trace_me
14: e8 fc ff ff ff call 15 <trace_me+0x15>
15: R_386_PC32 __cyg_profile_func_enter
19: a1 00 00 00 00 mov 0x0,%eax
1a: R_386_32 .bss
1e: 83 c0 01 add $0x1,%eax
21: a3 00 00 00 00 mov %eax,0x0
22: R_386_32 .bss
26: 8b 45 04 mov 0x4(%ebp),%eax
29: 89 44 24 04 mov %eax,0x4(%esp)
2d: c7 04 24 00 00 00 00 movl $0x0,(%esp)
30: R_386_32 trace_me
34: e8 fc ff ff ff call 35 <trace_me+0x35>
35: R_386_PC32 __cyg_profile_func_exit
39: c9 leave
3a: c3 ret Here we see that
mov %eax, 0x4(%esp)
movl $trace_me,(%esp)
call _cyg_profile_func_enteris added at the beginning and
mov %eax,0x4(%esp)
mov $trace_me,(%esp)
call __cyg_profile_func_exitis added at the end.
This is not 5 extra bytes but 27 extra bytes for a total of 32 bytes at every function.
========================================================
The overhead of -finstrument-functions is way too big. Remember, with using mcount, we can also patch away the callers. It's 5 bytes on both x86_64 and i386 and 4 bytes on most other archs. To patch away the -finstrument-functions would be too large, not to mention, you could not do it with nops. You whould have to have a jump, since patching more than one op code would lead to race conditions with a task being preempted in the middle of those nops.
I need to file this information away to give the next person that asks this question ;-)
Quoted 3 lines
Sorry again I didn't catch this and previous related threads earlier. I have some post-processing tools which might be useful here. Also, I've found it very handy to have the capability to filter by
minimum
Quoted 4 lines
function duration. Is there any work to do that with the current system. If not, maybe I could take a look at that and see if I can add something.
Actually, I probably should have Cc'd you anyway. I know you did similar work. You may be able to add that filtering to the dynamic ftrace so that the tracer will filter them out as well. If you want to work on this, feel free. There's already been a lot of good ideas (and code) coming from other developers :-)
-- Steve