lkml.org 
[lkml]   [2009]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: XFS stack overhead
    On Wed, 21 Oct 2009 14:21:54 -0500
    Eric Sandeen <sandeen@redhat.com> wrote:

    > > Also, the posting apparently mixes 'stack overhead' with 'runtime
    > > overhead'.
    >
    > right, that's why I asked, I'm not sure if stackprotector has runtime
    > overhead as well.
    >

    A bigger stack causes runtime overhead too because it increases the cache
    footprint of the workload.

    For the function I looked at the insn overhead was substantial:

    On entry:
    ffffffff8113ffa0: 48 83 ec 10 sub $0x10,%rsp
    ...
    ffffffff8113ffa9: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
    ffffffff8113ffb0: 00 00
    ffffffff8113ffb2: 48 89 45 f8 mov %rax,-0x8(%rbp)

    On exit:
    ffffffff81140000: 48 8b 55 f8 mov -0x8(%rbp),%rdx
    ffffffff81140004: 65 48 33 14 25 28 00 xor %gs:0x28,%rdx
    ffffffff8114000b: 00 00
    ffffffff8114000d: 74 13 je ffffffff81140022 <mem_cgroup_get_reclaim_stat_from_page+0x86>
    ...
    ffffffff8114001d: e8 ef 42 f2 ff callq ffffffff81064311 <__stack_chk_fail>

    So that's 37 extra bytes of code: 1 subtract, 4 reg/mem moves, an xor
    and a conditional jump that always get executed -- on every function
    call.

    And all that, in this case, for a function that doesn't even have any
    on-stack variables and can hardly be expected to be vulnerable to
    stack-smashing attacks.


    \
     
     \ /
      Last update: 2009-10-21 22:27    [W:0.045 / U:91.716 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site