On Mon, Mar 11, 2013 at 05:50:01PM -0400, Steven Rostedt wrote: > ------------------ original commit in Linus's tree ------------------ > > >From db05021d49a994ee40a9735d9c3cb0060c9babb8 Mon Sep 17 00:00:00 2001 > From: Steven Rostedt <srostedt@xxxxxxxxxx> > Date: Wed, 27 Feb 2013 21:48:09 -0500 > Subject: [PATCH] ftrace: Update the kconfig for DYNAMIC_FTRACE > > The prompt to enable DYNAMIC_FTRACE (the ability to nop and > enable function tracing at run time) had a confusing statement: > > "enable/disable ftrace tracepoints dynamically" > > This was written before tracepoints were added to the kernel, > but now that tracepoints have been added, this is very confusing > and has confused people enough to give wrong information during > presentations. > > Not only that, I looked at the help text, and it still references > that dreaded daemon that use to wake up once a second to update > the nop locations and brick NICs, that hasn't been around for over > five years. > > Time to bring the text up to the current decade. > > Cc: stable@xxxxxxxxxxxxxxx > Reported-by: Ezequiel Garcia <elezegarcia@xxxxxxxxx> > Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx> > > Index: linux-rt.git/kernel/trace/Kconfig > =================================================================== > --- linux-rt.git.orig/kernel/trace/Kconfig > +++ linux-rt.git/kernel/trace/Kconfig > @@ -386,24 +386,28 @@ config KPROBE_EVENT > If you want to use perf tools, this option is strongly recommended. > > config DYNAMIC_FTRACE > - bool "enable/disable ftrace tracepoints dynamically" > + bool "enable/disable function tracing dynamically" > depends on FUNCTION_TRACER > depends on HAVE_DYNAMIC_FTRACE > default y > help > - This option will modify all the calls to ftrace dynamically > - (will patch them out of the binary image and replace them > - with a No-Op instruction) as they are called. A table is > - created to dynamically enable them again. > + This option will modify all the calls to function tracing > + dynamically (will patch them out of the binary image and > + replace them with a No-Op instruction) on boot up. During > + compile time, a table is made of all the locations that ftrace > + can function trace, and this table is linked into the kernel > + image. When this is enabled, functions can be individually > + enabled, and the functions not enabled will not affect > + performance of the system. > + > + See the files in /sys/kernel/debug/tracing: > + available_filter_functions > + set_ftrace_filter > + set_ftrace_notrace > > This way a CONFIG_FUNCTION_TRACER kernel is slightly larger, but > otherwise has native performance as long as no tracing is active. > > - The changes to the code are done by a kernel thread that > - wakes up once a second and checks to see if any ftrace calls > - were made. If so, it runs stop_machine (stops all CPUS) > - and modifies the code to jump over the call to ftrace. > - > config FUNCTION_PROFILER > bool "Kernel function profiler" > depends on FUNCTION_TRACER Thanks, I'm queuing this for the 3.5 kernel as well. Cheers, -- Luis -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html