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, Adrian Bunk wrote:
    >
    > I had in mind that we anyway have to support it for tiny kernels.

    I actually don't think that is true.

    If we really were to decide to be stricter about it, and it makes a big
    size difference, we can probably also add a tool to warn about functions
    that really should be inline.

    > > Inlining really isn't the great tool some people think it is. Especially
    > > not since gcc stack allocation is so horrid that it won't re-use stack
    > > slots etc (which I don't disagree with per se - it's _hard_ to re-use
    > > stack slots while still allowing code scheduling).
    >
    > gcc's stack allocation has become better
    > (that's why we disable unit-at-a-time only for gcc 3.4 on i386).


    I agree that it has become better. But it still absolutely *sucks*.

    For example, see the patch I just posted about e1000 stack usage. Even
    though the variables were all in completely separate scopes, they all got
    individual space on the stack over the whole lifetime of the function,
    causing an explosion of stack-space. As such, gcc used 500 bytes too much
    of stack, just because it didn't re-use the stackspace.

    That was with gcc-4.3.0, and no, there were hardly any inlining issues
    involevd, although it is true that inlining actually did make it slightly
    worse in that case too (but since it was essentially a leaf function, that
    had little real life impact, since there were no deep callchains below it
    to care).

    So the fact is, "better" simply is not "good enough". We still need to do
    a lot of optimizations _manually_, because gcc cannot see that it can
    re-use the stack-slots.

    And sometimes those "optimizations" are actually performance
    pessimizations, because in order to make gcc not use all the stack at the
    same time, you simply have to break things out and force-disable inlining.

    > Most LOCs of the kernel are not written by people like you or Al Viro or
    > David Miller, and the average kernel developer is unlikely to do it as
    > good as gcc.

    Sure. But we do have tools. We do have checkstack.pl, it's just that it
    hasn't been an issue in a long time, so I suspect many people didn't even
    _realize_ we have it, and I certainly can attest to the fact that even
    people who remember it - like me - don't actually tend to run it all that
    often.

    > For the average driver the choice is realistically between
    > "inline's randomly sprinkled across the driver" and
    > "no inline's, leave it to gcc".

    And neither is likely to be a big problem.

    > BTW:
    > I just ran checkstack on a (roughly) allyesconfig kernel, and we have a
    > new driver that allocates "unsigned char recvbuf[1500];" on the stack...

    Yeah, it's _way_ too easy to do bad things.

    > With the "gcc inline's static functions" you complain about we have
    > 4-5 years of experience.

    Sure. And most of it isn't all that great.

    But I do agree that lettign gcc make more decisions is _dangerous_.
    However, in this case, at least, the decisions it makes would at least
    make for less inlining, and thus less stack space explosion.

    Linus


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