x86_64 Compiler Output Kernel Bloat v4.4

x86_64 Compiler Output Kernel Bloat v4.4

[Jeff Merkey]

Hi,

I noticed that in the assembler output for the x86_64 builds almost
every single function originating from C code has a nop instruction
that prefaces the function call.   I guess the concern with this is
the wasted space issue as each one of these placeholders takes up a
bunch of bytes at the head of each function.   Is there a reason this
assembler header is there in the first place to anyones knowledge?
Since every single function just about is prefaced by this inert 5
byte instruction it adds up to quite a bit of bloat in the size of the
linux executable.

0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0

The intel assembler format shows the bytes that comprise each
instruction.  The GDB format does not.  Both are provided.

0xffffffffa073e050 4155            push   r13
(0)> id mdb_watchdogs
mdb|mdb_watchdogs:
0xffffffffa073e010 mdb_watchdogs:         nopl   0x0(%rax,%rax,1)) <<
0xffffffffa073e015 mdb_watchdogs+0x5:     push   %rbp
0xffffffffa073e016 mdb_watchdogs+0x6:     mov    %rsp,%rbp
0xffffffffa073e019 mdb_watchdogs+0x9:     callq  0xffffffff811337e0
touch_softlockup_watchdog_sync
0xffffffffa073e01e mdb_watchdogs+0xe:     callq  0xffffffff810f0ba0
clocksource_touch_watchdog
0xffffffffa073e023 mdb_watchdogs+0x13:    callq  0xffffffff810dea20
rcu_cpu_stall_reset
0xffffffffa073e028 mdb_watchdogs+0x18:    callq  0xffffffff811337c0
touch_nmi_watchdog
0xffffffffa073e02d mdb_watchdogs+0x1d:    pop    %rbp
0xffffffffa073e02e mdb_watchdogs+0x1e:    data16
0xffffffffa073e030 mdb_watchdogs+0x20:    retq
0xffffffffa073e031 mdb_watchdogs+0x21:    nopw   %cs:0x0(%rax,%rax,1))
mdb|mdb:
0xffffffffa073e040 mdb:         nopl   0x0(%rax,%rax,1))  <<
0xffffffffa073e045 mdb+0x5:     push   %rbp
0xffffffffa073e046 mdb+0x6:     mov    %rsp,%rbp
0xffffffffa073e049 mdb+0x9:     push   %r15
0xffffffffa073e04b mdb+0xb:     push   %r14
0xffffffffa073e04d mdb+0xd:     mov    %rdi,%r14
0xffffffffa073e050 mdb+0x10:    push   %r13
(0)> u mdb_watchdogs
mdb|mdb_watchdogs:
0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0 <<
0xffffffffa073e015 55              push   rbp
0xffffffffa073e016 4889E5          mov    rbp,rsp
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

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Jeff Merkey]

On 1/18/16, Jeff Merkey <linux.mdb@gmail.com> wrote:
> Hi,
>
> I noticed that in the assembler output for the x86_64 builds almost
> every single function originating from C code has a nop instruction
> that prefaces the function call.   I guess the concern with this is
> the wasted space issue as each one of these placeholders takes up a
> bunch of bytes at the head of each function.   Is there a reason this
> assembler header is there in the first place to anyones knowledge?
> Since every single function just about is prefaced by this inert 5
> byte instruction it adds up to quite a bit of bloat in the size of the
> linux executable.
>
> 0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
>
> The intel assembler format shows the bytes that comprise each
> instruction.  The GDB format does not.  Both are provided.
>
> 0xffffffffa073e050 4155            push   r13
> (0)> id mdb_watchdogs
> mdb|mdb_watchdogs:
> 0xffffffffa073e010 mdb_watchdogs:         nopl   0x0(%rax,%rax,1)) <<
> 0xffffffffa073e015 mdb_watchdogs+0x5:     push   %rbp
> 0xffffffffa073e016 mdb_watchdogs+0x6:     mov    %rsp,%rbp
> 0xffffffffa073e019 mdb_watchdogs+0x9:     callq  0xffffffff811337e0
> touch_softlockup_watchdog_sync
> 0xffffffffa073e01e mdb_watchdogs+0xe:     callq  0xffffffff810f0ba0
> clocksource_touch_watchdog
> 0xffffffffa073e023 mdb_watchdogs+0x13:    callq  0xffffffff810dea20
> rcu_cpu_stall_reset
> 0xffffffffa073e028 mdb_watchdogs+0x18:    callq  0xffffffff811337c0
> touch_nmi_watchdog
> 0xffffffffa073e02d mdb_watchdogs+0x1d:    pop    %rbp
> 0xffffffffa073e02e mdb_watchdogs+0x1e:    data16
> 0xffffffffa073e030 mdb_watchdogs+0x20:    retq
> 0xffffffffa073e031 mdb_watchdogs+0x21:    nopw   %cs:0x0(%rax,%rax,1))
> mdb|mdb:
> 0xffffffffa073e040 mdb:         nopl   0x0(%rax,%rax,1))  <<
> 0xffffffffa073e045 mdb+0x5:     push   %rbp
> 0xffffffffa073e046 mdb+0x6:     mov    %rsp,%rbp
> 0xffffffffa073e049 mdb+0x9:     push   %r15
> 0xffffffffa073e04b mdb+0xb:     push   %r14
> 0xffffffffa073e04d mdb+0xd:     mov    %rdi,%r14
> 0xffffffffa073e050 mdb+0x10:    push   %r13
> (0)> u mdb_watchdogs
> mdb|mdb_watchdogs:
> 0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0 <<
> 0xffffffffa073e015 55              push   rbp
> 0xffffffffa073e016 4889E5          mov    rbp,rsp
> 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
>

here are some examples from in-tree code:

(2)> u async_schedule
async_schedule:
0xffffffff810a0210 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
0xffffffff810a0215 55              push   rbp
0xffffffff810a0216 48C7C2E0D79F81  mov    rdx,0xffffffff819fd7e0
0xffffffff810a021d 4889E5          mov    rbp,rsp
0xffffffff810a0220 E86BFEFFFF      call   __async_schedule
0xffffffff810a0225 5D              pop    rbp
0xffffffff810a0226 C3              ret
0xffffffff810a0227 660F1F840000000000  nop    WORD PTR [rax+rax]=0x0000
async_schedule_domain:
0xffffffff810a0230 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
0xffffffff810a0235 55              push   rbp
0xffffffff810a0236 4889E5          mov    rbp,rsp
0xffffffff810a0239 E852FEFFFF      call   __async_schedule
0xffffffff810a023e 5D              pop    rbp
0xffffffff810a023f C3              ret
current_is_async:
0xffffffff810a0240 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
0xffffffff810a0245 65488B3C2540BD0000  mov    rdi,gs:0xbd40
0xffffffff810a024e F6471420        test   BYTE PTR [rdi+20]=0x00,0x20
(2)> u schedule
schedule:
0xffffffff8167c280 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
0xffffffff8167c285 55              push   rbp
0xffffffff8167c286 65488B042540BD0000  mov    rax,gs:0xbd40
0xffffffff8167c28f 4889E5          mov    rbp,rsp
0xffffffff8167c292 53              push   rbx
0xffffffff8167c293 488B10          mov    rdx,QWORD PTR [rax]=0x0
0xffffffff8167c296 4885D2          test   rdx,rdx
0xffffffff8167c299 740A            je     schedule+0x25
(0xffffffff8167c2a5) (down)
0xffffffff8167c29b 4883B8080A000000  cmp    QWORD PTR [rax+0xa08]=0x0,0x0
0xffffffff8167c2a3 741E            je     schedule+0x43
(0xffffffff8167c2c3) (down)
0xffffffff8167c2a5 65488B1C2584410100  mov    rbx,gs:0x14184
0xffffffff8167c2ae 31FF            xor    edi,edi
0xffffffff8167c2b0 E8CBF8FFFF      call   __schedule
0xffffffff8167c2b5 488B8308C0FFFF  mov    rax,QWORD PTR
[rbx-0x3ff8]=0x4B53414D5F534B41
0xffffffff8167c2bc A808            test   al,0x8
0xffffffff8167c2be 75EE            jne    schedule+0x2e
(0xffffffff8167c2ae) (up)
0xffffffff8167c2c0 5B              pop    rbx
0xffffffff8167c2c1 5D              pop    rbp
0xffffffff8167c2c2 C3              ret
(2)> g

Jeff

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Jeff Merkey]

On 1/18/16, Jeff Merkey <linux.mdb@gmail.com> wrote:
> Hi,
>
> I noticed that in the assembler output for the x86_64 builds almost
> every single function originating from C code has a nop instruction
> that prefaces the function call.   I guess the concern with this is
> the wasted space issue as each one of these placeholders takes up a
> bunch of bytes at the head of each function.   Is there a reason this
> assembler header is there in the first place to anyones knowledge?
> Since every single function just about is prefaced by this inert 5
> byte instruction it adds up to quite a bit of bloat in the size of the
> linux executable.
>
> 0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
>
> The intel assembler format shows the bytes that comprise each
> instruction.  The GDB format does not.  Both are provided.
>
> 0xffffffffa073e050 4155            push   r13
> (0)> id mdb_watchdogs
> mdb|mdb_watchdogs:
> 0xffffffffa073e010 mdb_watchdogs:         nopl   0x0(%rax,%rax,1)) <<
> 0xffffffffa073e015 mdb_watchdogs+0x5:     push   %rbp
> 0xffffffffa073e016 mdb_watchdogs+0x6:     mov    %rsp,%rbp
> 0xffffffffa073e019 mdb_watchdogs+0x9:     callq  0xffffffff811337e0
> touch_softlockup_watchdog_sync
> 0xffffffffa073e01e mdb_watchdogs+0xe:     callq  0xffffffff810f0ba0
> clocksource_touch_watchdog
> 0xffffffffa073e023 mdb_watchdogs+0x13:    callq  0xffffffff810dea20
> rcu_cpu_stall_reset
> 0xffffffffa073e028 mdb_watchdogs+0x18:    callq  0xffffffff811337c0
> touch_nmi_watchdog
> 0xffffffffa073e02d mdb_watchdogs+0x1d:    pop    %rbp
> 0xffffffffa073e02e mdb_watchdogs+0x1e:    data16
> 0xffffffffa073e030 mdb_watchdogs+0x20:    retq
> 0xffffffffa073e031 mdb_watchdogs+0x21:    nopw   %cs:0x0(%rax,%rax,1))
> mdb|mdb:
> 0xffffffffa073e040 mdb:         nopl   0x0(%rax,%rax,1))  <<
> 0xffffffffa073e045 mdb+0x5:     push   %rbp
> 0xffffffffa073e046 mdb+0x6:     mov    %rsp,%rbp
> 0xffffffffa073e049 mdb+0x9:     push   %r15
> 0xffffffffa073e04b mdb+0xb:     push   %r14
> 0xffffffffa073e04d mdb+0xd:     mov    %rdi,%r14
> 0xffffffffa073e050 mdb+0x10:    push   %r13
> (0)> u mdb_watchdogs
> mdb|mdb_watchdogs:
> 0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0 <<
> 0xffffffffa073e015 55              push   rbp
> 0xffffffffa073e016 4889E5          mov    rbp,rsp
> 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.

Jeff

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Jeff Merkey]

On 1/18/16, Jeff Merkey <linux.mdb@gmail.com> wrote:
> On 1/18/16, Jeff Merkey <linux.mdb@gmail.com> wrote:
>> Hi,
>>
>> I noticed that in the assembler output for the x86_64 builds almost
>> every single function originating from C code has a nop instruction
>> that prefaces the function call.   I guess the concern with this is
>> the wasted space issue as each one of these placeholders takes up a
>> bunch of bytes at the head of each function.   Is there a reason this
>> assembler header is there in the first place to anyones knowledge?
>> Since every single function just about is prefaced by this inert 5
>> byte instruction it adds up to quite a bit of bloat in the size of the
>> linux executable.
>>
>> 0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0
>>
>> The intel assembler format shows the bytes that comprise each
>> instruction.  The GDB format does not.  Both are provided.
>>
>> 0xffffffffa073e050 4155            push   r13
>> (0)> id mdb_watchdogs
>> mdb|mdb_watchdogs:
>> 0xffffffffa073e010 mdb_watchdogs:         nopl   0x0(%rax,%rax,1)) <<
>> 0xffffffffa073e015 mdb_watchdogs+0x5:     push   %rbp
>> 0xffffffffa073e016 mdb_watchdogs+0x6:     mov    %rsp,%rbp
>> 0xffffffffa073e019 mdb_watchdogs+0x9:     callq  0xffffffff811337e0
>> touch_softlockup_watchdog_sync
>> 0xffffffffa073e01e mdb_watchdogs+0xe:     callq  0xffffffff810f0ba0
>> clocksource_touch_watchdog
>> 0xffffffffa073e023 mdb_watchdogs+0x13:    callq  0xffffffff810dea20
>> rcu_cpu_stall_reset
>> 0xffffffffa073e028 mdb_watchdogs+0x18:    callq  0xffffffff811337c0
>> touch_nmi_watchdog
>> 0xffffffffa073e02d mdb_watchdogs+0x1d:    pop    %rbp
>> 0xffffffffa073e02e mdb_watchdogs+0x1e:    data16
>> 0xffffffffa073e030 mdb_watchdogs+0x20:    retq
>> 0xffffffffa073e031 mdb_watchdogs+0x21:    nopw   %cs:0x0(%rax,%rax,1))
>> mdb|mdb:
>> 0xffffffffa073e040 mdb:         nopl   0x0(%rax,%rax,1))  <<
>> 0xffffffffa073e045 mdb+0x5:     push   %rbp
>> 0xffffffffa073e046 mdb+0x6:     mov    %rsp,%rbp
>> 0xffffffffa073e049 mdb+0x9:     push   %r15
>> 0xffffffffa073e04b mdb+0xb:     push   %r14
>> 0xffffffffa073e04d mdb+0xd:     mov    %rdi,%r14
>> 0xffffffffa073e050 mdb+0x10:    push   %r13
>> (0)> u mdb_watchdogs
>> mdb|mdb_watchdogs:
>> 0xffffffffa073e010 0F1F440000      nop    DWORD PTR [rax+rax]=0x0 <<
>> 0xffffffffa073e015 55              push   rbp
>> 0xffffffffa073e016 4889E5          mov    rbp,rsp
>> 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.
>
> Jeff
>

That's xor rax,rax

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Mihai Donțu]

On Mon, 18 Jan 2016 14:45:48 -0700 Jeff Merkey wrote:
> On 1/18/16, Jeff Merkey <linux.mdb@gmail.com> wrote:
> > On 1/18/16, Jeff Merkey <linux.mdb@gmail.com> wrote:  
> > > I noticed that in the assembler output for the x86_64 builds almost
> > > every single function originating from C code has a nop instruction
> > > that prefaces the function call.   I guess the concern with this is
> > > the wasted space issue as each one of these placeholders takes up a
> > > bunch of bytes at the head of each function.   Is there a reason this
> > > assembler header is there in the first place to anyones knowledge?
> > > Since every single function just about is prefaced by this inert 5
> > > byte instruction it adds up to quite a bit of bloat in the size of the
> > > linux executable.

If I'm not mistaking, those bytes are used to dynamically enable ftrace:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/trace/ftrace-design.txt

-- 
Mihai Donțu

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Jiri Olsa]

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

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Jeff Merkey]

On 1/19/16, Jiri Olsa <jolsa@redhat.com> wrote:
> 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
>

Takes up a lot of space since linux has so monay small functions.
Someone sent me the ftrace stuff and I looked over it.  Thanks.

Jeff

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Jeff Merkey]

On 1/19/16, Jeff Merkey <linux.mdb@gmail.com> wrote:
> On 1/19/16, Jiri Olsa <jolsa@redhat.com> wrote:
>> 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
>>
>
> Takes up a lot of space since linux has so monay small functions.
> Someone sent me the ftrace stuff and I looked over it.  Thanks.
>
> Jeff
>


I'll check my CONFIG and see if there's a way to turn this off.
vmlinux.o is at 385MB on my build -- about 20% of that is this NOP
instruction for a trace program that in most cases is probably never
used.  Oink ... Oink ... Oink ...

:-)

Jeff

Re: x86_64 Compiler Output Kernel Bloat v4.4

[Steven Rostedt]

On Tue, 19 Jan 2016 08:47:04 -0700
Jeff Merkey <linux.mdb@gmail.com> wrote:


> I'll check my CONFIG and see if there's a way to turn this off.
> vmlinux.o is at 385MB on my build -- about 20% of that is this NOP
> instruction for a trace program that in most cases is probably never
> used.  Oink ... Oink ... Oink ...
>

The bloat is well known and was a sacrifice for the feature. This
feature is optional. If you don't like it, simple disable all tracing.
Then you'll save a lot of kernel text.

-- Steve

Re: x86_64 Compiler Output Kernel Bloat v4.4

[H. Peter Anvin]

On January 20, 2016 6:40:35 AM PST, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Tue, 19 Jan 2016 08:47:04 -0700
>Jeff Merkey <linux.mdb@gmail.com> wrote:
>
>
>> I'll check my CONFIG and see if there's a way to turn this off.
>> vmlinux.o is at 385MB on my build -- about 20% of that is this NOP
>> instruction for a trace program that in most cases is probably never
>> used.  Oink ... Oink ... Oink ...
>>
>
>The bloat is well known and was a sacrifice for the feature. This
>feature is optional. If you don't like it, simple disable all tracing.
>Then you'll save a lot of kernel text.
>
>-- Steve

Also, looking at vmlinux.o for size is bogus - most of that is debugging information.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.