Re: x86: 4kstacks default - Kernel

This is a discussion on Re: x86: 4kstacks default - Kernel ; On Fri, 18 Apr 2008 17:37:36 GMT Linux Kernel Mailing List wrote: > Gitweb: http://git.kernel.org/git/?p=linux/k...70f676000a845a > Commit: d61ecf0b53131564949bc4196e70f676000a845a > Parent: f408b43ceedce49f26c01cd4a68dbbdbe2743e51 > Author: Ingo Molnar > AuthorDate: Fri Apr 4 17:11:09 2008 +0200 > Committer: Ingo Molnar > CommitDate: Thu ...

+ Reply to Thread
Page 1 of 8 1 2 3 ... LastLast
Results 1 to 20 of 154

Thread: Re: x86: 4kstacks default

  1. Re: x86: 4kstacks default

    On Fri, 18 Apr 2008 17:37:36 GMT
    Linux Kernel Mailing List wrote:

    > Gitweb: http://git.kernel.org/git/?p=linux/k...70f676000a845a
    > Commit: d61ecf0b53131564949bc4196e70f676000a845a
    > Parent: f408b43ceedce49f26c01cd4a68dbbdbe2743e51
    > Author: Ingo Molnar
    > AuthorDate: Fri Apr 4 17:11:09 2008 +0200
    > Committer: Ingo Molnar
    > CommitDate: Thu Apr 17 17:41:34 2008 +0200
    >
    > x86: 4kstacks default
    >
    > Signed-off-by: Ingo Molnar
    > ---
    > arch/x86/Kconfig.debug | 2 +-
    > 1 files changed, 1 insertions(+), 1 deletions(-)
    >
    > diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
    > index f4413c0..610aaec 100644
    > --- a/arch/x86/Kconfig.debug
    > +++ b/arch/x86/Kconfig.debug
    > @@ -106,8 +106,8 @@ config DEBUG_NX_TEST
    >
    > config 4KSTACKS
    > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > - depends on DEBUG_KERNEL
    > depends on X86_32
    > + default y


    This patch will cause kernels to crash.

    It has no changelog which explains or justifies the alteration.

    afaict the patch was not posted to the mailing list and was not
    discussed or reviewed.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: x86: 4kstacks default


    * Andrew Morton wrote:

    > > config 4KSTACKS
    > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > - depends on DEBUG_KERNEL
    > > depends on X86_32
    > > + default y

    >
    > This patch will cause kernels to crash.


    what mainline kernels crash and how will they crash? Fedora and other
    distros have had 4K stacks enabled for years:

    $ grep 4K /boot/config-2.6.24-9.fc9
    CONFIG_4KSTACKS=y

    and we've conducted tens of thousands of bootup tests with all sorts of
    drivers and kernel options enabled and have yet to see a single crash
    due to 4K stacks. So basically the kernel default just follows the
    common distro default now. (distros and users can still disable it)

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: x86: 4kstacks default

    Hi Ingo!

    with the older kernel is typical: xfs+nfs+4k stack(+lvm)



    On 4/19/08, Ingo Molnar wrote:
    >
    > * Andrew Morton wrote:
    >
    > > > config 4KSTACKS
    > > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > > - depends on DEBUG_KERNEL
    > > > depends on X86_32
    > > > + default y

    > >
    > > This patch will cause kernels to crash.

    >
    > what mainline kernels crash and how will they crash? Fedora and other
    > distros have had 4K stacks enabled for years:
    >
    > $ grep 4K /boot/config-2.6.24-9.fc9
    > CONFIG_4KSTACKS=y
    >
    > and we've conducted tens of thousands of bootup tests with all sorts of
    > drivers and kernel options enabled and have yet to see a single crash
    > due to 4K stacks. So basically the kernel default just follows the
    > common distro default now. (distros and users can still disable it)
    >
    > Ingo
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >



    --
    Thanks,
    Oliver
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: x86: 4kstacks default

    On Sat, Apr 19, 2008 at 04:23:29PM +0200, Ingo Molnar wrote:
    >
    > * Andrew Morton wrote:
    >
    > > > config 4KSTACKS
    > > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > > - depends on DEBUG_KERNEL
    > > > depends on X86_32
    > > > + default y

    > >
    > > This patch will cause kernels to crash.

    >
    > what mainline kernels crash and how will they crash? Fedora and other
    > distros have had 4K stacks enabled for years:


    If by other distros you mean RHEL then yes. However, openSUSE,
    Ubuntu, and Mandriva all still have 8K stacks. I know of no other
    distributions that default to 4K.

    --
    Shawn
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: x86: 4kstacks default

    On Sat, Apr 19, 2008 at 04:35:31PM +0200, Oliver Pinter wrote:
    >...
    > with the older kernel is typical: xfs+nfs+4k stack(+lvm)


    Does anyone still experience problems with 2.6.25?

    We all know that there once were problems, but if there are any left
    they should be reported and fixed.

    > Thanks,
    > Oliver


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: x86: 4kstacks default

    I dont know, thet this problem presentiert in 2.6.25, but im older
    kernels yes (2.6.22> or 2.6.23>).

    On 4/19/08, Adrian Bunk wrote:
    > On Sat, Apr 19, 2008 at 04:35:31PM +0200, Oliver Pinter wrote:
    > >...
    > > with the older kernel is typical: xfs+nfs+4k stack(+lvm)

    >
    > Does anyone still experience problems with 2.6.25?
    >
    > We all know that there once were problems, but if there are any left
    > they should be reported and fixed.
    >
    > > Thanks,
    > > Oliver

    >
    > cu
    > Adrian
    >
    > --
    >
    > "Is there not promise of rain?" Ling Tan asked suddenly out
    > of the darkness. There had been need of rain for many days.
    > "Only a promise," Lao Er said.
    > Pearl S. Buck - Dragon Seed
    >
    >



    --
    Thanks,
    Oliver
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: x86: 4kstacks default

    > On Sat, 19 Apr 2008 16:23:29 +0200 Ingo Molnar wrote:
    >
    > * Andrew Morton wrote:
    >
    > > > config 4KSTACKS
    > > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > > - depends on DEBUG_KERNEL
    > > > depends on X86_32
    > > > + default y

    > >
    > > This patch will cause kernels to crash.

    >
    > what mainline kernels crash and how will they crash?


    There has been a dribble of reports - I don't have the links handy, nor did
    I search for them.

    > Fedora and other
    > distros have had 4K stacks enabled for years:
    >
    > $ grep 4K /boot/config-2.6.24-9.fc9
    > CONFIG_4KSTACKS=y
    >
    > and we've conducted tens of thousands of bootup tests with all sorts of
    > drivers and kernel options enabled and have yet to see a single crash
    > due to 4K stacks.


    I doubt if you're testing things like nfsd-on-xfs-on-md-on-porky-scsi-driver.

    Enable CONFIG_DEBUG_STACK_USAGE. Monitor the results. It's so scary that
    I wonder if the feature is busted.

    > So basically the kernel default just follows the
    > common distro default now. (distros and users can still disable it)


    Apparently not. I wouldn't enable it if I had a distro.

    Anyway. We should be having this sort of discussion _before_ a patch
    gets merged, no?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: x86: 4kstacks default

    On Sat, 19 Apr 2008 09:59:48 -0500
    Shawn Bohrer wrote:

    > On Sat, Apr 19, 2008 at 04:23:29PM +0200, Ingo Molnar wrote:
    > >
    > > * Andrew Morton wrote:
    > >
    > > > > config 4KSTACKS
    > > > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > > > - depends on DEBUG_KERNEL
    > > > > depends on X86_32
    > > > > + default y
    > > >
    > > > This patch will cause kernels to crash.

    > >
    > > what mainline kernels crash and how will they crash? Fedora and
    > > other distros have had 4K stacks enabled for years:

    >
    > If by other distros you mean RHEL then yes. However, openSUSE,
    > Ubuntu, and Mandriva all still have 8K stacks. I know of no other
    > distributions that default to 4K.


    centos, oracle and redflag tend to follow the RHEL/fedora settings.

    To be honest, at this point we're at a situation where
    * Several very popular distributions have this enabled for 5+ years,
    apparently without any real issues (otherwise the enterprise releases
    would have turned this off)
    * The early "hot known issues" have been resolved afaik, things like
    block device stacking, and symlink recursion lookups are either no longer
    recursive, or a lot less recursive than they used to be.

    There are clear benefits to 4K stacks (no need to reiterate the flamewar,
    but worth mentioning)
    * Less memory consumption in the lowmem zone (critical for enterprise use,
    also good for general performance)
    * Kernel stacks at 8K are one of the most prominent order-1 allocations in the
    kernel; again with big-memory systems the fragmentation of the lowmem zone
    is a problem (and the distros that ship 4K stacks went there because of customer
    complaints)

    On the flipside the arguments tend to be
    1) certain stackings of components still runs the risk of overflowing
    2) I want to run ndiswrapper
    3) general, unspecified uneasyness.

    For 1), we need to know which they are, and then solve them, because even on x86-64 with 8k stacks
    they can be a problem (just because the stack frames are bigger, although not quite double, there).
    I've not seen any recent reports, I'll try to extend the kerneloops.org client to collect the
    "stack is getting low" warning to be able to see how much this really happens.

    for 2), the real answer there is "ndiswrapper needs 12kb not 8kb"

    for 3), this is hard to deal with but also generally unfounded... you can use this argument against any change in the kernel.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: x86: 4kstacks default


    * Arjan van de Ven wrote:

    > On Sat, 19 Apr 2008 09:59:48 -0500
    > Shawn Bohrer wrote:
    >
    > > On Sat, Apr 19, 2008 at 04:23:29PM +0200, Ingo Molnar wrote:
    > > >
    > > > * Andrew Morton wrote:
    > > >
    > > > > > config 4KSTACKS
    > > > > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > > > > - depends on DEBUG_KERNEL
    > > > > > depends on X86_32
    > > > > > + default y
    > > > >
    > > > > This patch will cause kernels to crash.
    > > >
    > > > what mainline kernels crash and how will they crash? Fedora and
    > > > other distros have had 4K stacks enabled for years:

    > >
    > > If by other distros you mean RHEL then yes. However, openSUSE,
    > > Ubuntu, and Mandriva all still have 8K stacks. I know of no other
    > > distributions that default to 4K.

    >
    > centos, oracle and redflag tend to follow the RHEL/fedora settings.
    >
    > To be honest, at this point we're at a situation where
    > * Several very popular distributions have this enabled for 5+ years,
    > apparently without any real issues (otherwise the enterprise releases
    > would have turned this off)
    > * The early "hot known issues" have been resolved afaik, things like
    > block device stacking, and symlink recursion lookups are either no longer
    > recursive, or a lot less recursive than they used to be.
    >
    > There are clear benefits to 4K stacks (no need to reiterate the flamewar,
    > but worth mentioning)
    > * Less memory consumption in the lowmem zone (critical for enterprise use,
    > also good for general performance)
    > * Kernel stacks at 8K are one of the most prominent order-1 allocations in the
    > kernel; again with big-memory systems the fragmentation of the lowmem zone
    > is a problem (and the distros that ship 4K stacks went there because of customer
    > complaints)
    >
    > On the flipside the arguments tend to be
    > 1) certain stackings of components still runs the risk of overflowing
    > 2) I want to run ndiswrapper
    > 3) general, unspecified uneasyness.
    >
    > For 1), we need to know which they are, and then solve them, because
    > even on x86-64 with 8k stacks they can be a problem (just because the
    > stack frames are bigger, although not quite double, there). I've not
    > seen any recent reports, I'll try to extend the kerneloops.org client
    > to collect the "stack is getting low" warning to be able to see how
    > much this really happens.
    >
    > for 2), the real answer there is "ndiswrapper needs 12kb not 8kb"
    >
    > for 3), this is hard to deal with but also generally unfounded... you
    > can use this argument against any change in the kernel.


    and lets observe it that 8K stacks are of course still offered, so if
    anyone disables 4K stacks in the .config, it will stay disabled.

    Ingo
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: x86: 4kstacks default

    Ingo Molnar wrote:
    > and lets observe it that 8K stacks are of course still offered, so if
    > anyone disables 4K stacks in the .config, it will stay disabled.


    While you change the default, maybe move it also from the "Kernel
    hacking" menu into the "General setup" menu? An option with default=y
    is probably not an option that is targeted towards kernel hackers only.
    --
    Stefan Richter
    -=====-==--- -=-- =--==
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: x86: 4kstacks default

    Adrian Bunk wrote:
    > On Sat, Apr 19, 2008 at 04:35:31PM +0200, Oliver Pinter wrote:
    >> ...
    >> with the older kernel is typical: xfs+nfs+4k stack(+lvm)

    >
    > Does anyone still experience problems with 2.6.25?


    There are always problems. You can always come up with something that
    will crash in 4k, IMHO.

    Rather than foisting this upon everyone, I'd rather see work put into
    making stack size a boot parameter or something, so that people can
    choose what's appropriate for their workload (or their IO stack, if you
    prefer).

    -Eric

    > We all know that there once were problems, but if there are any left
    > they should be reported and fixed.
    >
    >> Thanks,
    >> Oliver

    >
    > cu
    > Adrian
    >


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: x86: 4kstacks default

    Arjan van de Ven wrote:

    > On the flipside the arguments tend to be
    > 1) certain stackings of components still runs the risk of overflowing
    > 2) I want to run ndiswrapper
    > 3) general, unspecified uneasyness.
    >
    > For 1), we need to know which they are, and then solve them, because even on x86-64 with 8k stacks
    > they can be a problem (just because the stack frames are bigger, although not quite double, there).


    Except, apparently, not, at least in my experience.

    Ask the xfs guys if they see stack overflows on x86_64, or on x86.

    I've personally never seen common stack problems with xfs on x86_64, but
    it's very common on x86. I don't have a great answer for why, but
    that's my anecdotal evidence.

    > I've not seen any recent reports, I'll try to extend the kerneloops.org client to collect the
    > "stack is getting low" warning to be able to see how much this really happens.


    That sounds like a very good thing to collect, and maybe if I re-send a
    "clearly state stack overflows at oops time" patch you can easily keep tabs.

    Thanks,

    -Eric
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: x86: 4kstacks default

    Ingo Molnar wrote:
    > * Andrew Morton wrote:
    >
    >>> config 4KSTACKS
    >>> bool "Use 4Kb for kernel stacks instead of 8Kb"
    >>> - depends on DEBUG_KERNEL
    >>> depends on X86_32
    >>> + default y

    >> This patch will cause kernels to crash.

    >
    > what mainline kernels crash and how will they crash? Fedora and other
    > distros have had 4K stacks enabled for years:
    >
    > $ grep 4K /boot/config-2.6.24-9.fc9
    > CONFIG_4KSTACKS=y
    >
    > and we've conducted tens of thousands of bootup tests with all sorts of
    > drivers and kernel options enabled and have yet to see a single crash
    > due to 4K stacks.


    Really, not one?

    https://bugzilla.redhat.com/show_bug.cgi?id=247158
    https://bugzilla.redhat.com/show_bug.cgi?id=227331
    https://bugzilla.redhat.com/show_bug.cgi?id=240077

    (hehe, ok, xfs is a common component there...)

    and it's not always obvious that you've overflowed the stack.

    CONFIG_DEBUG_STACKOVERFLOW isn't ery useful because the warning printk
    it generates uses the remaining amount of stack, and tips the box.

    > So basically the kernel default just follows the
    > common distro default now. (distros and users can still disable it)


    If Fedora is the common distro, ok.

    Fedora is a pretty narrow sample in terms of IO stacks at least. I have
    plenty of fondness for Fedora, but it's almost 100% ext3[1]. I spent a
    fair amount of time getting xfs+lvm to survive 4k on F8; gcc caused
    stack usage to grow in general from F7 to F8, and F9 seems to have
    gotten tight again but I haven't gotten to the bottom of yet.

    Heck my ext3-root-on-sda1 pre-beta F9 box, no nfs or lvm or xfs or
    anything gets within 744 bytes of the end of the 4k stack simply by
    *booting* (it was a modprobe process... maybe some module needs help)

    How many other distros use 4K stacks on x86, really?

    -Eric

    [1] http://www.smolts.org/static/stats/stats.html shows 24588 ext3
    filesystems, compared to 366 xfs, 248 reiserfs, 76 jfs ...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: x86: 4kstacks default

    On Sat, 19 Apr 2008 21:36:16 -0500
    Eric Sandeen wrote:


    > > For 1), we need to know which they are, and then solve them,
    > > because even on x86-64 with 8k stacks they can be a problem (just
    > > because the stack frames are bigger, although not quite double,
    > > there).

    >
    > Except, apparently, not, at least in my experience.


    if you actually go over on x86, it's not unlikely that you're getting close to the edge on 64 bit.

    At minimum we really do want to fix these things...

    > I've personally never seen common stack problems with xfs on x86_64,
    > but it's very common on x86. I don't have a great answer for why, but
    > that's my anecdotal evidence.


    One thing I've learned with the kerneloops.org work is that people don't read
    their dmesg.....
    >
    > > I've not seen any recent reports, I'll try to extend the
    > > kerneloops.org client to collect the "stack is getting low" warning
    > > to be able to see how much this really happens.

    >
    > That sounds like a very good thing to collect, and maybe if I re-send
    > a "clearly state stack overflows at oops time" patch you can easily
    > keep tabs.


    .... which makes me think we need to strengthen this part of the kernel.
    (and then have kerneloops.org collect the issues)

    If there's a clear pattern in the backtraces we will find it.
    And then we can fix it... which is absolutely the right thing,
    I don't think anyone disagrees with that.

    So yes if you can dig up your patch, yes please!


    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: x86: 4kstacks default

    On Sat, Apr 19, 2008 at 08:56:09PM -0500, Eric Sandeen wrote:
    > Adrian Bunk wrote:
    > > On Sat, Apr 19, 2008 at 04:35:31PM +0200, Oliver Pinter wrote:
    > >> ...
    > >> with the older kernel is typical: xfs+nfs+4k stack(+lvm)

    > >
    > > Does anyone still experience problems with 2.6.25?

    >
    > There are always problems. You can always come up with something that
    > will crash in 4k, IMHO.


    We are going from 6k to 4k.

    Your "You can always come up with something that will crash in" point
    would be invariant to this change (although it might be harder to
    trigger in real life).

    > Rather than foisting this upon everyone, I'd rather see work put into
    > making stack size a boot parameter or something, so that people can
    > choose what's appropriate for their workload (or their IO stack, if you
    > prefer).


    Why should users have to poke with such deeply internal things?
    That doesn't sound right.

    Excessive stack usage in the kernel is considered to be a bug.

    We should identify and fix all remaining problems (if any).

    > -Eric


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: x86: 4kstacks default

    On Sat, Apr 19, 2008 at 09:59:48AM -0500, Shawn Bohrer wrote:
    > On Sat, Apr 19, 2008 at 04:23:29PM +0200, Ingo Molnar wrote:
    > >
    > > * Andrew Morton wrote:
    > >
    > > > > config 4KSTACKS
    > > > > bool "Use 4Kb for kernel stacks instead of 8Kb"
    > > > > - depends on DEBUG_KERNEL
    > > > > depends on X86_32
    > > > > + default y
    > > >
    > > > This patch will cause kernels to crash.

    > >
    > > what mainline kernels crash and how will they crash? Fedora and other
    > > distros have had 4K stacks enabled for years:

    >
    > If by other distros you mean RHEL then yes. However, openSUSE,
    > Ubuntu, and Mandriva all still have 8K stacks. I know of no other
    > distributions that default to 4K.


    MontaVista offers 4k stacks for arm (currently an external patch) and
    markets that as a feature to customers, so many of them might use it.

    In-kernel the sh and m68knommu ports also offer 4k stacks (for both
    archs there's also a defconfig using it), and the mn10300 port contains
    an #ifdef but no config option.

    The stack problems in the kernel tend to not be in arch code, and if
    we don't get i386 to always run with 4k stacks there's no chance that
    it will ever work reliably on other architectures.

    > Shawn


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 09:06:23AM +0100, Alan Cox wrote:
    > > The stack problems in the kernel tend to not be in arch code, and if
    > > we don't get i386 to always run with 4k stacks there's no chance that
    > > it will ever work reliably on other architectures.

    >
    > Not really the case - embedded tends not to use deep stacks of drivers.


    Something like nfsd-over-xfs-over-raid is (or was) the most common
    problem - and this or similar stackings might be used in NAS devices.

    > Alan


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: x86: 4kstacks default

    > The stack problems in the kernel tend to not be in arch code, and if
    > we don't get i386 to always run with 4k stacks there's no chance that
    > it will ever work reliably on other architectures.


    Not really the case - embedded tends not to use deep stacks of drivers.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: x86: 4kstacks default

    On Sun, 20 Apr 2008 11:51:04 +0300
    Adrian Bunk wrote:

    > On Sun, Apr 20, 2008 at 09:06:23AM +0100, Alan Cox wrote:
    > > > The stack problems in the kernel tend to not be in arch code, and if
    > > > we don't get i386 to always run with 4k stacks there's no chance that
    > > > it will ever work reliably on other architectures.

    > >
    > > Not really the case - embedded tends not to use deep stacks of drivers.

    >
    > Something like nfsd-over-xfs-over-raid is (or was) the most common
    > problem - and this or similar stackings might be used in NAS devices.


    Specific cases yes, but such NAS devices have big processors and are not
    little emdedded CPUs. On an embedded box you know at build time what it
    will be doing.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 10:36:11AM +0100, Alan Cox wrote:
    > On Sun, 20 Apr 2008 11:51:04 +0300
    > Adrian Bunk wrote:
    >
    > > On Sun, Apr 20, 2008 at 09:06:23AM +0100, Alan Cox wrote:
    > > > > The stack problems in the kernel tend to not be in arch code, and if
    > > > > we don't get i386 to always run with 4k stacks there's no chance that
    > > > > it will ever work reliably on other architectures.
    > > >
    > > > Not really the case - embedded tends not to use deep stacks of drivers.

    > >
    > > Something like nfsd-over-xfs-over-raid is (or was) the most common
    > > problem - and this or similar stackings might be used in NAS devices.

    >
    > Specific cases yes, but such NAS devices have big processors and are not
    > little emdedded CPUs. On an embedded box you know at build time what it
    > will be doing.


    The code in the kernel that gets the fewest coverage at all are our
    error paths, and some vendor might try 4k stacks, validate it works in
    all use cases - and then it will blow up in some error condition he
    didn't test.

    6k is known to work, and there aren't many problems known with 4k.

    And from a QA point of view the only way of getting 4k thoroughly tested
    by users, and well also tested in -rc kernels for catching regressions
    before they get into stable kernels, is if we get 4k stacks enabled
    unconditionally on i386.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 8 1 2 3 ... LastLast