Re: [2.6 patch] i386: always use 4k stacks

[Arjan van de Ven <arjan@infradead.org>]

On Wed, 2005-11-16 at 11:18 +0100, Wed, 16 Nov 2005 11:18:12 +0100
wrote:
> El Wed, 16 Nov 2005 09:03:32 +0100,
> Arjan van de Ven <arjan@infradead.org> escribió:
> 
> 
> > * more stack space is available for interrupts compared to 2.4 kernels
> >    - in 2.4 kernels only 2Kb was available for interrupt context (to
> >      keep 4K available for user context). With complex softirqs such as
> >      PPP and firewall rules and nested interrupts this wasn't always
> >      enough. Compared to 2.6-with-8Kstacks is a bit harder; there is
> >      2Kb extra available there compared to 2.4 and arguably some of that
> >      extra is for interrupts.
> 
> 
> I would like to contribute that listing with two non-technical reasons
> more:
> 
>  * Encourages good code. Due to the 4 Kb stacks patch several parts of
> 	the kernel have gone on diet, improving the quality of the code

this argument I agree with. especially since 64 bit platforms have a
higher stack footprint by nature (bigger call frames and more to store
on the stack) and if x86 allows stackbloat, the other architectures get
in trouble and are going to need really large stacks.

>  * Some distros are enabling 4KB (fedora), other distros aren't, so
> 	having a single stack size option will make 3rd party modules
> 	distribution easier (some propietary drivers may not be caring
> 	about making their drivers work with 4Kb stacks due to the lack
> 	of uniformity)

this I don't see as a reason; illegal drivers should never be a reason
to clutter our kernel one way or the other. And for GPL 3rd party
drivers the problem isn't there realistically. If they were reliable in
2.4, they're reliable with 2.6+4K stacks. If they're not then they need
to be fixed (eg your previous point).

-
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/