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 <[email protected]>
> 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: [email protected]
> Reported-by: Ezequiel Garcia <[email protected]>
> Signed-off-by: Steven Rostedt <[email protected]>
> 
> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to