Re: 4k stacks in 2.6

[Bill Davidsen]

Andrea Arcangeli wrote:
> On Thu, May 27, 2004 at 04:03:22PM +0200, Arjan van de Ven wrote:
>
> > In theory you are absolutely right, problem is the current macro..... it's
> > SO much easier to have one stacksize everywhere (and cheaper too) for
> > this... (and it hasn't been a problem so far, esp since the softirq's have
>
>
> I see the problem, but then why don't we wait to implement it right, to
> allow 8k irq-stacks before merging into mainline?
>
> grep for "~s 4k" (i.e. the word "4[kK]" in the subject) on l-k and
> you'll see there's more than just nvidia. one user reported not being
> able to boot at all with 4k stacks since 2.6.6 doesn't have a stack
> overflow in the oops, so I hope he tested w/ and w/o 4KSTACKS option
> enabled to be able to claim what broke his machine is the 4KSTACKS
> option. (his oops doesn't reveal a stack overflow, the thread_info is at
> 0xf000 and the esp is at 0xffxx)
>
> Making it a config option, is a sort of proof that you agree it can
> break something, or you wouldn't make it a config option in the first
> place. What's the point of making it a configuration option if it cannot
> break anything and if it's not risky? Making it a config option is not
> good, because then some developer may develop leaving 4KSTACKS disabled,
> and then his kernel code might break on the users with 4KSTACKS enabled
> (it's not much different from PREEMPT).  Amittedly code that overflows
> 4k is likely to be not legitimate but not all code is good (the most
> common error is to allocate big strutures locally on the stack with
> local vars), and if developers are able to notice the overflow on their
> own testing it's better.

We have lots of options which may cause problems but are useful for 
special situations, why is this one any different? The only actual 
benefit I've seen quoted for 4k stack is that it improves fork 
performance if memory is so fragmented that there is no 8k block left. 
And my first thought on hearing that was if that's common the VM should 
be investigated. This is a stable kernel, and breaking even such an 
abomination as a binary-only driver for the sake of whoever has this 
vastly fragmented memory seems to be the anthesis of stable.

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/