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

[Helge Hafting <helge.hafting@aitel.hist.no>]

Parag Warudkar wrote:

>
> On Dec 18, 2005, at 12:43 AM, Andi Kleen wrote:
>
>> You can catch the obvious ones, but the really hard ones
>> that only occur under high load in obscure exceptional
>> circumstances with large configurations and suitable nesting you  won't.
>> These would be only found at real world users.
>
>
> Yep, as it all depends on code complexity, some of these cases might  
> not be "errors" at all - instead for that kind of functionality they  
> might _require_ bigger stacks.
>
No complex problem ever requires a big stack.  It may require a large amount
of memory - which can be allocated explicitly outside the stack.

> If you have 64 bit machines common place and memory a lot cheaper I  
> don't see how it is beneficial to force smaller stack sizes without  
> giving consideration to the code complexity, architecture and  
> requirements.
> (Solaris for example, seems to be going to have 16Kb kernel stacks on  
> 64 bit machines.)
>
> So, please let's leave stack size as an option for users to choose  
> and stop this 4Kb stack war. May be after a little rest I will start  
> another one demanding 16Kb stacks :)

I suggest a little experiment for you.  Make a kernel module which do 
nothing
except try to allocate 16k of _contigous_ kernel memory, and
printk whether it succeeded or failed before exiting.  Have cron run that
every 5 minutes.  After a few weeks of running this low-impact test on
a busy loaded server, look at statistics about how often the 16k allocation
worked - and how often it failed. 

Whatever failure rate you get, expect the same failure rate for server
processes forking to handle new connections while running with 16k stacks.
Failing one out of a hundred times would probably not be tolerated
for a webserver, and I suspect the failure rate for this will be higher - if
the machine has a reasonable memory load and the usual fragmentation.

On the other hand, if you can surprise us about how this works very
well - then you have a strong argument!

Helge Hafting