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

[Tiezhu Yang]

On 06/21/2021 10:00 PM, Steven Rostedt wrote:
> On Mon, 21 Jun 2021 09:21:31 +0800
> Tiezhu Yang <yangtiezhu@xxxxxxxxxxx> 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

OK, I see, thank you very much.

Thanks,
Tiezhu