ftrace/x86_32: Remove support for non DYNAMIC_FTRACE
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Fri, 10 May 2019 16:05:46 +0000 (12:05 -0400)
committerSteven Rostedt (VMware) <rostedt@goodmis.org>
Fri, 10 May 2019 16:33:03 +0000 (12:33 -0400)
commit518049d9d3e25dcd7be6e3d728e86f292ad0c922
treefdc458e59447517e471a9113d8f32f11cb4d4a8d
parenta15fd609ad53a631a927c6680e8fb606f42a712b
ftrace/x86_32: Remove support for non DYNAMIC_FTRACE

When DYNAMIC_FTRACE is enabled in the kernel, all the functions that can be
traced by the function tracer have a "nop" placeholder at the start of the
function. When function tracing is enabled, the nop is converted into a call
to the tracing infrastructure where the functions get traced. This also
allows for specifying specific functions to trace, and a lot of
infrastructure is built on top of this.

When DYNAMIC_FTRACE is not enabled, all the functions have a call to the
ftrace trampoline. A check is made to see if a function pointer is the
ftrace_stub or not, and if it is not, it calls the function pointer to trace
the code. This adds over 10% overhead to the kernel even when tracing is
disabled.

When an architecture supports DYNAMIC_FTRACE there really is no reason to
use the static tracing. I have kept non DYNAMIC_FTRACE available in x86 so
that the generic code for non DYNAMIC_FTRACE can be tested. There is no
reason to support non DYNAMIC_FTRACE for both x86_64 and x86_32. As the non
DYNAMIC_FTRACE for x86_32 does not even support fentry, and we want to
remove mcount completely, there's no reason to keep non DYNAMIC_FTRACE
around for x86_32.

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
arch/x86/Kconfig
arch/x86/kernel/ftrace_32.S