Re: [RFC PATCH 1/2] ftrace: Introduce cmdline argument ftrace_disabled

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 21 Jun 2021 09:21:31 +0800
Tiezhu Yang <yangtiezhu@loongson.cn> wrote:

> >
> > You have no rationale for this change. What's the purpose of this?  
> 
> The "System Benchmarks Index Score" of UnixBench under FUNCTION_TRACER
> is lower than !FUNCTION_TRACER, I want to use this new cmdline argument
> ftrace_disabled to test it, this is the original intention.
> 
> I see the following help info of "config FUNCTION_TRACER":
> 
> [If it's runtime disabled (the bootup default), then the overhead of the
> instructions is very small and not measurable even in micro-benchmarks.]

Those benchmarks were done a long time ago, and they may be measurable today :-/

> 
> I am not quite understand the above description, could you tell me how to
> avoid the runtime performance overhead under FUNCTION_TRACER?

Anyway, your patch wont do anything to change the benchmarks.

When CONFIG_FUNCTION_TRACER is enabled, on x86_64, most functions will
start with a call to fentry. At boot up, these functions will be
converted over to become a nop. And thinking about it, "ftrace_disable"
stops all conversions, so if you add that to the kernel command line,
those calls to fentry, wont be converted to nops, and you'll make
things much worse!

Now, some versions of gcc (and perhaps clang) can do the conversion to
nops at compile time (in which case, your patch would keep the nops and
not the calls to fentry).

The overhead that FUNCTION_TRACER adds is the 5 byte nop at the start
of most functions. This causes a slight hit to instruction cache, and a
minuscule amount of time in the instruction pipeline of the CPU. This
is the "overhead" that is talked about. Your patch doesn't do anything
to address it. The only way to remove that overhead is to compile the
kernel without CONFIG_FUNCTION_TRACER.

-- Steve