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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <db070d1c-9320-378e-52b5-a7d551e0f1a6@loongson.cn>
Date:   Tue, 22 Jun 2021 09:19:21 +0800
From:   Tiezhu Yang <yangtiezhu@...ngson.cn>
To:     Steven Rostedt <rostedt@...dmis.org>
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 06/21/2021 10:00 PM, Steven Rostedt wrote:
> 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

OK, I see, thank you very much.

Thanks,
Tiezhu