|| ||Arjan van de Ven <firstname.lastname@example.org>|
|| ||Shawn Bohrer <email@example.com>|
|| ||Re: x86: 4kstacks default|
|| ||Sat, 19 Apr 2008 11:00:34 -0700|
|| ||Ingo Molnar <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Thomas Gleixner <email@example.com>|
On Sat, 19 Apr 2008 09:59:48 -0500
Shawn Bohrer <firstname.lastname@example.org> wrote:
> On Sat, Apr 19, 2008 at 04:23:29PM +0200, Ingo Molnar wrote:
> > * Andrew Morton <email@example.com> 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
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.