lkml.org 
[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected


    On Tue, 26 Aug 2008, Jamie Lokier wrote:
    >
    > A function which is only called from one place should, if everything
    > made sense, _never_ use more stack through being inlined.

    But that's simply not true.

    See the whole discussion.

    The problem is that if you inline that function, the stack usage of the
    newly inlined function is now added to ALL THE OTHER paths too!

    So the case we had in module loading was that yes, we had a function with
    a big stack footprint, but it was NOT in the deep path.

    But by inlining it, it now moved the stack footprint "up" one level to
    another function, and now the big stack footprint really _was_ in the deep
    path, because the caller was involved in a much deeper chain.

    So inlining moves the code up the callchain, and that is a problem for the
    backtrace, but that's "just" a debugging issue. But it also moves the
    stack footprint up the callchain, and that can actually be a correctness
    issue.

    Of course, a compiler doesn't _have_ to do that. A compiler _could_ have
    multiple different stack footprints for a single function, and do liveness
    analysis etc. But no sane compiler probably does that, because it's very
    painful indeed, and it's not even an issue if you aren't stack-limited
    (and being stack-limited is really just a kernel thing).

    (Yeah, it can be an issue even if you have a big stack, in that you get
    worse cache behaviour, so a dense stack footprint _would_ help. But the
    complexity of stack liveness analysis is almost certainly not worth the
    relatively small gains it would get on some odd cases).

    Linus


    \
     
     \ /
      Last update: 2008-08-26 21:23    [W:4.078 / U:0.232 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site