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 Wed, 27 Aug 2008, Adrian Bunk wrote:
    > >
    > > We're much better off with a 1% code-size reduction than forcing big
    > > stacks on people. The 4kB stack option is also a good way of saying "if it
    > > works with this, then 8kB is certainly safe".
    >
    > You implicitely assume both would solve the same problem.

    I'm just saying that your logic doesn't hold water.

    If we can save kernel stack usage, then a 1% increase in kernel size is
    more than worth it.

    > While 4kB stacks are something we anyway never got 100% working

    What? Don't be silly.

    Linux _historically_ always used 4kB stacks.

    No, they are likely not usable on x86-64, but dammit, they should be more
    than usable on x86-32 still.

    > But I do not think the problem you'd solve with
    > -fno-inline-functions-called-once is big enough to warrant the size
    > increase it causes.

    You continually try to see the inlining as a single solution to one
    problem (debuggability, stack, whatever).

    The biggest problem with gcc inlining has always been that it has been
    _unpredictable_. It causes problems in many different ways. It has caused
    stability issues due to gcc versions doing random things. It causes the
    stack expansion. It makes stack traces harder for debugging, etc.

    If it was any one thing, I wouldn't care. But it's exactly the fact that
    it causes all these problems in different areas.

    Linus


    \
     
     \ /
      Last update: 2008-08-27 01:55    [W:4.141 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site