linux-kernel - Re: [RFC PATCH 1/2] ftrace: Introduce cmdline argument ftrace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Jun 2021 10:00:04 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc:     Ingo Molnar <mingo@...hat.com>, Jonathan Corbet <corbet@....net>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Xuefeng Li <lixuefeng@...ngson.cn>
Subject: Re: [RFC PATCH 1/2] ftrace: Introduce cmdline argument
 ftrace_disabled

On Mon, 21 Jun 2021 09:21:31 +0800
Tiezhu Yang <yangtiezhu@...ngson.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