lkml.org 
[lkml]   [2008]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: x86: 4kstacks default
    Adrian Bunk wrote:
    > On Sun, Apr 20, 2008 at 09:05:40AM -0500, Eric Sandeen wrote:
    >> Adrian Bunk wrote:
    >>
    >>> But the more users will get 4k stacks the more testing we have, and the
    >>> better both existing and new bugs get shaken out.
    >>>
    >>> And if there were only 4k stacks in the vanilla kernel, and therefore
    >>> all people on i386 testing -rc kernels would get it, that would give a
    >>> better chance of finding stack regressions before they get into a
    >>> stable kernel.
    >> Heck, maybe you should make it 2k by default in all -rc kernels; that
    >> way when people run -final with the 4k it'll be 100% bulletproof, right?
    >> 'cause all those piggy drivers that blow a 2k stack will finally have
    >> to get fixed?
    >
    > I'm arguing for aiming at having all 32bit architectures with 4k page
    > size using the same stack size. Not for having -rc kernels differ from
    > release kernels.

    Oh, I know. I'm just saying that 4k seems chosen out of convenience for
    memory management, without any real correlation to what you might
    actually need to run a thread. They do happen to be roughly equivalent
    for many cases, but not all. Setting a default which is not safe for
    several common use cases does not seem wise...

    I guess what I'm saying is, I don't agree that any callchain which needs
    more than 4k of stack indicates brokenness that must be fixed, as
    various posts in this thread seem to suggest.

    Sure, 1k char buffers on the stack and massive structs and unlimited
    recursion we can agree on as things to fix, but complex/deep/stacked
    callchains which don't fit in 4k are much more of a grey area.

    -Eric


    \
     
     \ /
      Last update: 2008-04-20 16:59    [W:4.981 / U:0.200 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site