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
