From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1757347AbcASHjh (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Jan 2016 02:39:37 -0500
Received: from mx1.redhat.com ([209.132.183.28]:51296 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751689AbcASHjf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Jan 2016 02:39:35 -0500
Date: Tue, 19 Jan 2016 08:39:30 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Jeff Merkey <linux.mdb@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
        Andy Lutomirski <luto@amacapital.net>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        Steven Rostedt <rostedt@goodmis.org>, Borislav Petkov <bp@alien8.de>,
        Jiri Olsa <jolsa@kernel.org>
Subject: Re: x86_64 Compiler Output Kernel Bloat v4.4
Message-ID: <20160119073930.GA20358@krava.brq.redhat.com>
References: <CAO6TR8Urw0ndhxocX63qJXGw1FD2XNfoiGD70_B-+dCSnJh30A@mail.gmail.com>
 <CAO6TR8WW6Nkc-StZLHD5_FcF4SjajfQMsrchQVH6-+WYzc2-7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAO6TR8WW6Nkc-StZLHD5_FcF4SjajfQMsrchQVH6-+WYzc2-7A@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Jan 18, 2016 at 02:45:14PM -0700, Jeff Merkey wrote:

SNIP

> > 0xffffffffa073e019 E8C2579FE0      call   touch_softlockup_watchdog_sync
> > 0xffffffffa073e01e E87D2B9BE0      call   clocksource_touch_watchdog
> > 0xffffffffa073e023 E8F8099AE0      call   rcu_cpu_stall_reset
> > 0xffffffffa073e028 E893579FE0      call   touch_nmi_watchdog
> > 0xffffffffa073e02d 5D              pop    rbp
> > 0xffffffffa073e02e 6690            data16
> > 0xffffffffa073e030 C3              ret
> > 0xffffffffa073e031 6666666666662E0F1F840000000000  nop    cs:WORD PTR
> > [rax+rax]=0x0000
> > mdb|mdb:
> > 0xffffffffa073e040 0F1F440000      nop    DWORD PTR [rax+rax]=0x0  <<
> > 0xffffffffa073e045 55              push   rbp
> > 0xffffffffa073e046 4889E5          mov    rbp,rsp
> > 0xffffffffa073e049 4157            push   r15
> > 0xffffffffa073e04b 4156            push   r14
> > 0xffffffffa073e04d 4989FE          mov    r14,rdi
> > 0xffffffffa073e050 4155            push   r13
> > (0)> g
> >
> > Jeff
> >
> 
> I think xor eax,eax is a lot shorter and fewer bytes.

that 5 byte nop gets replaced by call instruction once the
function trace is enabled

explained in CONFIG_FUNCTION_TRACER option doc:


config FUNCTION_TRACER
        bool "Kernel Function Tracer"
        depends on HAVE_FUNCTION_TRACER
        select KALLSYMS
        select GENERIC_TRACER
        select CONTEXT_SWITCH_TRACER
        help
          Enable the kernel to trace every kernel function. This is done
          by using a compiler feature to insert a small, 5-byte No-Operation
          instruction at the beginning of every kernel function, which NOP
          sequence is then dynamically patched into a tracer call when
          tracing is enabled by the administrator. If it's runtime disabled
          (the bootup default), then the overhead of the instructions is very
          small and not measurable even in micro-benchmarks.

jirka